System, method, and non-transitory computer readable medium for constructing troubleshooting tree

Abstract

To provide a greatly quick system, method, and non-transitory computer readable medium for extracting and structuring information from a non-structured text source and automatically constructing an initial instance of a troubleshooting tree.SOLUTION: A method includes receiving a non-structured text source including a sensor and segmenting it to a section associated with a component, a unit, or a process of an apparatus by using a parsing tool. Metadata including a text and a page range unique to the section is acquired for each section, and non-static processing obtains data having enhanced similarity matching and segmented as a result. An indexing process includes embedding the data in an index note together with the metadata to improve search efficiency, creating a catalog including a failure, a cause, or repair recommendation by using a pre-trained language model, and structuring at least some of the failure, cause, and repair recommendation as an index node of a troubleshooting tree.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates generally to hierarchical data structures, and more particularly to systems, methods, and non-transitory computer-readable media for creating, organizing, and representing information in the form of troubleshooting trees and similar data structures. [Background technology]

[0002] Building a troubleshooting tree for a specific device or system is an elaborate process requiring the collaboration of a multidisciplinary team including engineers, domain experts, and technicians. The process typically begins with a comprehensive analysis of the system's architecture, operations, and known failure modes. This involves referencing equipment manuals, past maintenance records, and input from subject matter experts to extract and map relevant information into a meaningful representation of the troubleshooting tree in an organized manner. The information gathered from these sources is used to draft an initial tree structure, which is then refined through iterative testing and validation, incorporating real-world data and feedback from field staff. This collaborative effort ensures that the troubleshooting tree is an accurate, reliable, and adaptable resource for addressing problems quickly and effectively.

[0003] In industrial fields, troubleshooting trees serve as an important tool for failure analysis and diagnosis within complex systems and processes. A troubleshooting tree is a graphical representation that visualizes the decision-making process and can be used to identify and correct problems affecting industrial machinery or operations, thereby reducing downtime. Each node in the tree represents a specific diagnostic test or observation, and the branches emanating from these nodes indicate potential outcomes or diagnostic steps. By working step-by-step through the tree's logical flow, technicians and engineers can efficiently use questions, decisions, and tests to identify failures and determine the root cause of problems, streamlining maintenance procedures, for example. Additionally, troubleshooting trees are useful for training new personnel because they provide a standardized, easy-to-understand path for systematic troubleshooting. Summary of the Invention [Problem to be solved by the invention]

[0004] In practice, building a troubleshooting tree is a tedious process that can take months to validate, which is important, and ensure the reliability of the information contained in the troubleshooting tree.

[0005] Therefore, a significantly faster system and method is desirable that can extract and structure information from unstructured text sources and automatically build an initial instance of a troubleshooting tree. [Means for solving the problem]

[0006] In some aspects of the present disclosure, a method for building a troubleshooting tree for an equipment comprises performing, in a pre-processing pipeline, the steps of receiving an unstructured text source including sections; segmenting the unstructured text source and using a parser to extract a list of respective sections associated with at least one of an equipment, unit, or process component; providing the unstructured text source to a pre-trained language model in response to determining that the parser has not completely extracted the list; and instructing the pre-trained language model to identify each section by using the list of sections as context; obtaining, for each section, metadata including section-specific text associated with the unstructured text source and a corresponding page range; and applying a non-static process that increases consistency of similarity matching to pre-process the sections to obtain segmented data. performing steps including: using an indexing process that improves search efficiency in a troubleshooting tree building pipeline by embedding the segmented data and metadata in index nodes; using the index nodes of the troubleshooting tree building pipeline to generate a catalog including faults, causes, or repair recommendations for each component using a pre-trained language model; and structuring at least some of the faults, causes, and repair recommendations as nodes of a troubleshooting tree; generating a troubleshooting tree in response to at least one of the equipment, unit, or process being queried by a user query; and a rationale process that includes cross-referencing at least a portion of the troubleshooting tree with an unstructured text source, wherein the rationale process evaluates the accuracy of the troubleshooting tree and uses the metadata; and outputting the troubleshooting tree.

[0007] In some embodiments, one or more of the index nodes include preprocessed text data.

[0008] In some aspects, the method further includes extracting new text data from the updated unstructured text, using a pre-trained language model to generate troubleshooting branches associated with previously unidentified problems, integrating the troubleshooting branches into a troubleshooting tree to obtain an updated troubleshooting tree, and validating the troubleshooting tree against the new source material to improve accuracy.

[0009] In some embodiments, the troubleshooting tree is structured to facilitate extension and enrichment using data from previously unseen, unstructured text sources.

[0010] In some embodiments, the user query includes a prompt that generates an output, such as a Python list, that includes at least one of the following for one or more steps: components, faults, causes, or repair recommendations.

[0011] In some embodiments, the unstructured text source includes at least one of a service log, a service manual, or an owner's manual.

[0012] Instructing the pre-trained language model to identify each section further includes instructing the pre-trained language model to identify each section as a separate set of documents.

[0013] In some embodiments, a pre-trained language model uses a search expansion generation process to search for information.

[0014] In some embodiments, the rationalization process further includes evaluating the output of a pre-trained language model against the context used to search for the information, or providing references to one or more sections containing information that enable user verification of the accuracy of the troubleshooting tree to improve output accuracy.

[0015] In some aspects, the techniques described herein are a non-transitory computer-readable medium for storing instructions for performing a process, the instructions including performing, in a pre-processing pipeline, steps including: receiving an unstructured text source including sections; segmenting the unstructured text source and using a parser to extract a list of respective sections associated with at least one of an equipment, unit, or process component; providing the unstructured text source to a pre-trained language model in response to determining that the parser has not completely extracted the list; and instructing the pre-trained language model to identify each section by using the list of sections as context; obtaining, for each section, metadata including section-specific text associated with the unstructured text source and a corresponding page range; and applying a non-static process that increases consistency of similarity matching to pre-process the sections to obtain segmented data. performing steps including: using an indexing process that improves search efficiency in a troubleshooting tree building pipeline by embedding segmented data and metadata into index nodes; using the index nodes of the troubleshooting tree building pipeline to generate a catalog including faults, causes, or repair recommendations for each component using a pre-trained language model; and structuring at least some of the faults, causes, and repair recommendations as nodes of a troubleshooting tree; generating a troubleshooting tree in response to at least one of the equipment, unit, or process being queried by a user query; and a rationale process including cross-referencing at least a portion of the troubleshooting tree with an unstructured text source, wherein the rationale process evaluates the accuracy of the troubleshooting tree and uses the metadata; and outputting the troubleshooting tree.Related to non-transitory computer-readable media.

[0016] Aspects of the present disclosure may involve a system, which may include means for constructing a troubleshooting tree for an equipment, the system including, in a preprocessing pipeline, means for receiving an unstructured text source including sections; means for segmenting the unstructured text source to extract a list of sections, each section associated with at least one of an equipment, a unit, or a process component; means for performing the steps including: providing the unstructured text source to a pre-trained language model; and instructing the pre-trained language model to identify each section by using the list of sections as context; for each section, obtaining metadata including section-specific text associated with the unstructured text source and a corresponding page range; and applying non-static processing to increase consistency of similarity matching to pre-process the section to obtain segmented data; and means for using an indexing process to improve search efficiency in the troubleshooting tree building pipeline by embedding the acquired data and metadata into index nodes; means for using the index nodes of the troubleshooting tree building pipeline to perform steps including: generating, for each component, a catalog including faults, causes, or repair recommendations using a pre-trained language model; and structuring at least some of the faults, causes, and repair recommendations as nodes of the troubleshooting tree; means for generating a troubleshooting tree in response to at least one of the equipment, unit, or process being queried by a user query; means for using the metadata in the rationale process to evaluate the accuracy of the troubleshooting tree, the rationale process including cross-referencing at least a portion of the troubleshooting tree with an unstructured text source; and means for outputting the troubleshooting tree. [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 illustrates a general hierarchical troubleshooting tree structure. [Figure 2] FIG. 1 illustrates a typical pipeline for search expansion generation (RAG). [Figure 3] FIG. 2 is an exemplary text preprocessing and indexing pipeline diagram according to various embodiments of the present disclosure. [Figure 4] 1 is a flowchart illustrating an example process for building a troubleshooting tree for an appliance using a large language model (LLM), according to various embodiments of the present disclosure. [Figure 5] 1 is a flowchart illustrating an example process for building a troubleshooting tree for an appliance, according to various embodiments of the present disclosure. [Figure 6] FIG. 1 illustrates an exemplary computing environment having an exemplary computing device suitable for use in some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0018] The following detailed description provides details of the figures and exemplary implementations of the present application. Reference numbers and descriptions of elements that are duplicated between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the word "automatic" can include fully automatic or semi-automatic implementations, including user or administrator control over certain aspects of the implementation, depending on the desired implementation of one skilled in the art practicing the embodiments of the present application. Selections can be made by a user via a user interface or other input means, or can be implemented via a desired algorithm. The exemplary implementations as described herein can be used either alone or in combination, and the functionality of the exemplary implementations can be implemented via any means depending on the desired implementation. The terms "troubleshooting tree" and "diagnostic tree" are used interchangeably herein.

[0019] FIG. 1 illustrates a typical hierarchical troubleshooting tree structure. The troubleshooting tree structure 100 includes nodes, each representing a piece of information or concept, and branches (edges) of the troubleshooting tree structure 100 that indicate relationships between parent nodes and child nodes. The troubleshooting tree structure 100 of FIG. 1 provides a clear (single) path from the root node to all other nodes, and each node except the root node has one parent node. Conversely, each parent node has a one-to-many relationship with its child nodes.

[0020] Note that the troubleshooting tree structure 100 is a four-stage structure, but the depth of the troubleshooting tree structure 100 can vary depending on the complexity of the information. Furthermore, note that unlike knowledge graphs, which are non-hierarchical graphs, the edges of a well-defined troubleshooting tree structure 100 do not need to be labeled to indicate interrelationships between nodes and single parent-child connections.

[0021] As shown in Figure 1, an exemplary troubleshooting tree structure 100 includes a root node section in a first stage 102, which represents a piece of equipment; a second stage 104, which represents machine or equipment components; a third stage 106, which identifies possible faults; a fourth stage 108, which represents possible causes of the faults; and a final stage 110, which provides a recommended repair process.

[0022] While the top node in the first stage 102 of the troubleshooting tree structure 100 represents the equipment itself, the nodes relevant to troubleshooting begin with the equipment / system components or parts. Therefore, the component nodes in the second stage 104 are hereinafter referred to as root nodes. At this level of the troubleshooting tree structure 100, a technician can select the root node most relevant to the problem to begin the troubleshooting process. The nodes in the second stage 104 provide an overview of possible component failures, allowing the technician to perform relevant tests to identify the specific underlying failure in the system. If the nodes in the third stage 106 represent all possible causes of the failure identified in the second stage, they can guide the technician to perform prescribed tests to isolate the specific cause. The final stage 110 identifies recommended repair actions to remedy the corresponding causes identified in the previous fourth stage 108. Note that the width and depth of the troubleshooting tree structure 100 in FIG. 1 are merely examples, and a suitable troubleshooting tree can have any width or depth depending on the requirements of a particular application.

[0023] LLMs are known as machine learning models designed to generate text that closely resembles human language. These models operate by calculating the likelihood of a sequence of tokens in text, where a token represents the finest element of text, such as a word, subword, character, or byte. The usefulness of language models spans a wide range of tasks, including natural language understanding, generating text that mimics human writing, language translation, entity recognition, text summarization, and question answering.

[0024] LLMs have not been used in the context of directly generating troubleshooting trees; instead, they generate knowledge graphs (KGs), which lack the rich causal information found in troubleshooting trees. Furthermore, LLMs have contextual limitations, i.e., the number of tokens that can be used as inputs and outputs is limited (e.g., 8192 tokens in GPT-4). However, many documents, such as service manuals, often contain text that far exceeds the limits set for LLMs. A possible solution is to utilize search expansion generation (RAGs).

[0025] Figure 2 shows a typical RAG pipeline, which integrates an information retrieval mechanism that identifies and fetches only the most relevant contextual information from large external data sources based on a user query. These relatively small batches of documents, along with the original user query, then serve as input to the LLM to form an augmented context that generates more consistent and relevant responses.

[0026] Various embodiments herein utilize preprocessing methods that consider the underlying structure of a service manual. An exemplary preprocessing method includes segmenting text based on sections or subsections of the manual. Sections in a service manual are typically based on a single component, unit, or specific process associated with a machine. Many queries on service manuals tend to be directed to a specific component or process. Section-based text chunking ensures that the LLM has access to the context of the entire component or process when generating output, thereby reducing incompleteness. In embodiments, sections are identified and section-specific text can be extracted as separate documents (or chunks) with little or no human intervention.

[0027] FIG. 3 illustrates an exemplary text preprocessing and indexing pipeline diagram according to various embodiments of the present disclosure. In step 302, a document parser is used to extract a table of contents from a product service manual. Then, in step 304, it is determined whether the attempt to extract the table of contents failed. If so, in step 306, an LLM is utilized to extract section names and corresponding page numbers, followed by human verification of the results in step 308. In step 310, metadata (e.g., section name, starting page number, ending page number, etc.) is collected for each section and included in the index node during indexing. This metadata can be used for output rationalization. Finally, in step 312, the preprocessed and indexed text data can be used in a troubleshooting tree building pipeline.

[0028] In an embodiment, the troubleshooting tree construction process may include a structured information extraction task. According to the structure of the troubleshooting tree shown in FIG. 1, an embodiment may generate a troubleshooting tree construction pipeline that extracts information through the layers of the troubleshooting tree in a depth-first manner. The pipeline may build a fault tree in a two-step approach. For example, given a particular document, step 1 may represent generating a list of components / parts or systems as the root node, and step 2 may represent generating a branch of the fault tree for each of the components generated in step 1.

[0029] In an embodiment, step 1 may use the entire context of the device (e.g., the full service manual) as input, along with a prompt to the LLM to generate a list of components or parts that make up a piece of device. An example prompt for step 1 may be structured as follows:

[0030] "Using the provided service manual, construct a troubleshooting tree guide for [equipment]. First, list all of the major physical parts and components of [equipment] using the service manual as context. Next, identify and list all of the major physical components (i.e., mechanical parts) of [equipment]. Finally, output a python list of the major parts, following the example [engine, hydraulic system]."

[0031] This particular prompt is structured to first provide the LLM with an overall idea of ​​the task and instructions on how to identify and extract the target information from the given context. Finally, the prompt provides output instructions with examples. The output list of components identified in step 1 can be used as the root node of a troubleshooting tree, as shown in Figure 1.

[0032] In an embodiment, given a root node representing a component or part in [equipment], step 2 may involve extracting information representing subsequent nodes in the branch. Two exemplary structured prompt-based processes are presented to perform this step.

[0033] The first process, Process 1, performs targeted information extraction for each subsequent node in the troubleshooting tree in a depth-first manner. Process 1 1. Preprocessing and information-based text chunking Step 1 2. Index the text using "list indexing" 3. Generate a list of components / parts for the equipment Step 2 4. For each component: Prompt: Construct a troubleshooting tree for [equipment], using the service manual as context, to identify all possible failures of [component] of [equipment]. Identify and list all possible faults in [component] of [equipment] using the provided context. Output a Python list of faults in the format [fault1,fault2]. 5. For each failure, Prompt: Using the service manual, construct a troubleshooting tree guide for [equipment]. Using the provided context, identify and list all possible causes of failure [failure] in [component] of [equipment]. Output a python list of causes in the format [cause 1, cause 2]. 6. For each cause, Prompt: Identify the repair method for cause [cause] of failure [failure] that occurred in [component] of [equipment] using the provided context. Output only the most relevant repair recommendations. The output should be formatted as a python list variable. An example output is [repair recommendation]. 7. Aggregate all extracted information and structure it as a troubleshooting tree. 8. Manual intervention may be required to clean formatting errors and duplicate information.

[0034] The method proposed in Process 1 provides a methodical, step-by-step prompt structure for extracting data at each level. The prompts are tailored to extract information specific to each level, and there are also instructions on how to format the output. This ensures that the output of the LLM is structured in a consistent manner for aggregation and post-processing.

[0035] In certain applications, the recursive prompt formulation suggested in Process 1 can quickly become expensive, for example, for large input service manuals.

[0036] Therefore, various embodiments leverage the capabilities of powerful LLMs such as GPT-4 to understand and follow complex structured prompts, using direct prompts to generate troubleshooting tree branches instead of step-by-step information extraction, as outlined in Process 2 below. Process 2 1. Preprocessing and information-based text chunking Step 1 2. Indexing text using "list indexing" 3. Generate a list of components / parts for the equipment Step 2 4. For each component: Prompt: Using the given context, construct a troubleshooting tree to investigate possible problems with [component] of [equipment]. Output only a table representing the fault tree. The format of the table is as follows: The first column of the table, entitled "Components", contains the component names, with empty cells filled with NaN. Each row in the second column of the table, entitled "Possible Faults", contains all possible faults in the "Component", with empty cells filled with NaN. Each row in the third column of the table has a column entitled "Possible Cause" with all the possible causes associated with each corresponding fault listed in the second column. The fourth column, entitled "Repair Recommendation," specifies a repair recommendation for each corresponding cause in the third column. If a troubleshooting tree cannot be constructed according to the specified problem using the given context, then respond with "None." 5. Aggregate all extracted information and structure it as a troubleshooting tree. 6. Manual intervention may be required to clean formatting errors and duplicate information.

[0037] The method proposed in Process 2 significantly simplifies the troubleshooting tree generation process by avoiding the recursive prompts used in Process 1. However, the resulting prompts are relatively more complex and depend on the LLM's ability to understand the general concept of a "troubleshooting tree" and the specific formatting instructions.

[0038] 4 is a flowchart illustrating an exemplary process for building a troubleshooting tree for an instrument using an LLM, in accordance with various embodiments of the present disclosure. In an embodiment, process 400 begins at step 402, where a preprocessing pipeline receives unstructured text.

[0039] At step 404, it is determined whether process 400 has access to the state-of-the-art LLM. If not, then at step 406, process 400 applies Process 1. If access is available, process 400 resumes at step 406 where it applies Process 2.

[0040] In an embodiment, Process 1 is a recursive prompt generation process that involves data indexing, component generation, recursive and iterative prompt generation of fault causes, and repair recommendations. The pipeline for Process 1 utilizes prompts with a relatively simple structure compared to Process 2 and exhaustive information extraction for high coverage. System performance typically improves proportionally to the capacity of the LLM used.

[0041] On the other hand, Process 2 is a direct prompt generation process that involves data indexing, component generation, and direct prompt generation of a fault tree for each component's cause. Process 2 utilizes prompts with a relatively complex structure that is ideal for advanced LLM. Process 2 is faster, consumes fewer resources, and may result in a lower coverage rate.

[0042] The output of each process is cleaned for parsing errors and duplicate information at step 408. Table 1 below shows an example troubleshooting tree branch generated in accordance with various embodiments herein.

[0043] It should be noted that, unlike traditional troubleshooting trees constructed and validated by engineers, LLMs are known to be prone to generating erroneous or irrelevant information. Therefore, for embodiments utilizing LLMs herein, it is desirable to have a system and method for verifying their accuracy in order to obtain reliable information, an important aspect in industrial applications. Accordingly, various embodiments may ground the information extracted for each node in source material. To accomplish this, the output of the LLM for each node may be evaluated against the context used to retrieve the information. Such evaluation can be further achieved by utilizing section and / or subsection metadata maintained throughout the preprocessing pipeline (Figure 2), for example, by providing a reference to a section in a service manual that contains the relevant information. In this way, a user can relatively easily verify the accuracy of the information associated with each entry, for example, by detecting hallucinations, thereby improving the reliability of the output.

[0044] [Table 1] As shown in Table 1, given a particular component, each specific failure can branch into several causes, each of which can lead to a specific repair action or recommendation.

[0045] While the present invention has been generally described in the context of creating and displaying troubleshooting trees for equipment as troubleshooting charts to aid in the decision-making process, it should be understood that the systems and methods for troubleshooting trees described herein can be used with any other type of classification system, and this is not intended to limit the scope of the present disclosure to such embodiments. Some embodiments can be applied to enhance or extend existing troubleshooting trees, involving documentation of problems such as repair and maintenance logs. For example, in embodiments, new text data can be extracted from the updated unstructured text, and a pre-trained language model can be used to generate troubleshooting branches related to previously unidentified problems. The branches can then be integrated into the troubleshooting tree to obtain an updated troubleshooting tree. Furthermore, the troubleshooting tree can be validated against new source material to increase accuracy.

[0046] 5 is a flowchart illustrating an exemplary process for building a troubleshooting tree for an instrument, according to various embodiments of the present disclosure. In an embodiment, process 500 may begin at step 502, where a preprocessing pipeline receives an unstructured text source containing one or more sections. Advantageously, the preprocessing pipeline is optimized for the troubleshooting tree extraction process, as well as for LLM-based RAG use cases.

[0047] In step 504, a parser may be used to segment the unstructured text source to extract, for example, a list of sections, each section associated with at least one of a piece of equipment, a unit, or a component of a process.

[0048] If, in step 506, it is determined that the parser has not completely extracted the list, the unstructured text source may be provided to a pre-trained language model instructed to use the list of sections as context to identify each section.

[0049] In step 508, metadata may be obtained for each section including section-specific text and corresponding page ranges associated with the unstructured text source, and a non-static process may be applied to pre-process the sections to obtain segmented data. Advantageously, this increases the consistency of similarity matching when RAG techniques are used.

[0050] At step 510, an indexing process may be used to improve search efficiency in the troubleshooting tree building pipeline by embedding the segmented data and metadata into index nodes.

[0051] The index node may be used in a troubleshooting tree construction pipeline in step 512. The pipeline may perform steps including using a pre-trained language model to generate, for each component, a catalog containing faults, causes, or repair recommendations, and structuring at least some of them as nodes in a troubleshooting tree.

[0052] At step 514, a troubleshooting tree may be generated in response to at least one of the equipment, units, or processes being queried by the user query.

[0053] In step 516, the metadata may be used in a rationale process to evaluate the accuracy of the troubleshooting tree. This rationale process may include cross-referencing at least a portion of the troubleshooting tree with unstructured text sources. In this way, the rationale process increases the reliability of the information in the troubleshooting tree and provides a means to cross-check with source data for validation.

[0054] Finally, in step 518, a troubleshooting tree may be output. In this manner, the pipeline can automatically generate an initial instance of a troubleshooting tree using various sources of information, such as service manuals. If necessary, the initial instance can be verified and refined by a human with relatively little effort for ultimate use.

[0055] Advantageously, in applications such as creating troubleshooting trees, this can significantly reduce the time consumption, potentially saving months.

[0056] Those skilled in the art will recognize that: (1) certain steps may be performed optionally; (2) steps are not limited to the particular order described herein; (3) certain steps may be performed in a different order; and (4) certain steps may occur simultaneously.

[0057] 6 illustrates an exemplary computing environment having an exemplary computing device suitable for use in some embodiments. The computing device 605 in the computing environment 600 can include one or more processing units, cores, or processors 610, memory 615 (e.g., RAM, ROM, and / or the like), internal storage 620 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or I / O interface 625, any of which can be coupled over a communication mechanism or bus 630 for communicating information or can be incorporated into the computing device 605. The I / O interface 625 can be further configured to receive images from a camera or provide images to a projector or display, depending on the desired implementation.

[0058] Computing device 605 may be communicatively coupled to input / user interface 635 and output device / interface 640. Either or both of input / user interface 635 and output device / interface 640 may be wired or wireless interfaces and may be detachable. Input / user interface 635 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touchscreen interface, keyboard, pointing / cursor control, microphone, camera, Braille, motion sensor, optical reader, and / or the like). Output device / interface 640 may include a display, television, monitor, printer, speaker, Braille, or the like. In some exemplary implementations, input / user interface 635 and output device / interface 640 may be incorporated with or physically coupled to computing device 605. In other implementations, other computing devices may function as or provide the functionality of input / user interface 635 and output device / interface 640 for computing device 605.

[0059] Examples of computing devices 605 may include highly mobile devices (e.g., smartphones, devices mounted on vehicles and other machines, devices carried by people or animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded and / or televisions with one or more processors coupled thereto, radios, and the like).

[0060] Computing device 605 may be communicatively coupled (e.g., via I / O interface 625) to external storage 645 and network 650 for communication with any number of networked components, devices, and systems, including one or more computing devices of the same or different configurations. Computing device 605 or any connected computing device may function as, provide services to, or be referred to as a server, client, thin server, general-purpose machine, special-purpose machine, or otherwise.

[0061] I / O interface 625 may include wired and / or wireless interfaces using any communication or I / O protocol or convention (e.g., Ethernet, 802.11x, Universal System Bus, WiMax, modem, cellular network protocols, and the like) for communicating information to and / or from at least all connected components, devices, and networks in computing environment 600. Network 650 may be any network or combination of networks (e.g., the Internet, a local area network, a wide area network, a telephone network, a cellular network, a satellite network, and the like).

[0062] The computing device 605 may use and / or communicate using computer-usable or computer-readable media, including transitory and non-transitory media. Transitory media include transmission media (e.g., metallic cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD-ROMs, digital video disks, Blu-ray® disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

[0063] The computing device 605 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some exemplary computing environments. The computer-executable instructions can be retrieved from transitory media and stored on and retrieved from non-transitory media. The executable instructions can be from one or more of any programming, scripting, and machine language (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, etc.).

[0064] The processor 610 can run under any operating system (OS) (not shown) in a native or virtual environment. One or more applications can be deployed, including a logic unit 660, an application programming interface (API) unit 665, an input unit 670, an output unit 675, and an inter-unit communication mechanism 695 for different units to communicate with each other, with the OS, and with other applications (not shown). The above-mentioned units and elements can vary in design, function, configuration, or implementation and are not limited to the above description. The processor 610 can have the form of a hardware processor, such as a central processing unit (CPU), or can be a combination of hardware and software units.

[0065] In some examples, when information or instructions for execution are received by API unit 665, it may be communicated to one or more other units (e.g., logic unit 660, input unit 670, output unit 675). In some examples, logic unit 660 may be configured to control the flow of information between units and direct the services provided by API unit 665, input unit 670, and output unit 675 in some of the examples described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 660 alone or in conjunction with API unit 665. Input unit 670 may be configured to obtain inputs for calculations described in examples, and output unit 675 may be configured to provide outputs based on the calculations described in examples.

[0066] The processor 610 may be configured to execute a method or computer instructions that may involve performing steps including receiving an unstructured text source including sections in a pre-processing pipeline, for example as described with respect to FIG. 3 ; segmenting the unstructured text source and using a parser to extract a list of each section associated with at least one of the components of the equipment, unit, or process; and, in response to the parser determining that it has not completely extracted the list, providing the unstructured text source to a pre-trained language model; and instructing the pre-trained language model to identify each section by using the list of sections as context.

[0067] For each section, the processor 610 may perform steps including obtaining metadata including section-specific text and corresponding page ranges associated with the unstructured text source, for example as shown in FIG. 3, and pre-processing the section to obtain segmented data by applying non-static processing that increases the consistency of similarity matching.

[0068] The processor 610 can use an indexing process to improve search efficiency in the troubleshooting tree building pipeline by embedding the segmented data and metadata into index nodes, as shown in FIG. 1 , and perform steps including: for each component, using a pre-trained language model to generate a catalog containing faults, causes, or repair recommendations; and structuring at least some of the faults, causes, or repair recommendations as nodes in a troubleshooting tree.

[0069] The processor 610 may generate a troubleshooting tree in response to at least one of the equipment, units, or processes being queried by a user query, as shown in FIG. 3, and may use the metadata in a rationale process to evaluate the accuracy of the troubleshooting tree, which may include cross-referencing at least a portion of the troubleshooting tree with an unstructured text source, and output the troubleshooting tree.

[0070] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the substance of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In exemplary implementations, the performed steps require physical manipulations of tangible quantities to achieve a tangible result.

[0071] Unless otherwise specified, and as will be apparent from the description, throughout this specification, descriptions utilizing words such as "processing," "calculating," "computing," "determining," "displaying," or the like, are understood to include the actions and processes of a computer system or other information processing device that manipulates and converts data represented as physical (electronic) quantities in the registers and memory of the computer system into other data similarly represented as physical quantities in the memory or registers of the computer system or other information storage, transmission, or display devices.

[0072] Exemplary embodiments may further relate to apparatuses for performing the operations herein. This apparatus may be specially constructed for the desired purposes, or may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored on a computer-readable medium, such as a computer-readable storage medium or a computer-readable signal medium. Computer-readable storage media may include tangible media such as optical disks, magnetic disks, read-only memory, random-access memory, solid-state devices and drives, or any other type of tangible or non-transitory medium suitable for storing electronic information. Computer-readable signal media may include media such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. A computer program may include a pure software implementation containing instructions for performing the operations of a desired embodiment.

[0073] Various general-purpose systems may be used with the programs and modules according to the examples herein, or it may prove convenient to construct specialized apparatus to perform the desired method steps. Moreover, the exemplary embodiments are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​may be used to implement the techniques of the examples as described herein. Instructions in the programming language may be executed by one or more processing devices, such as, for example, a central processing unit (CPU), processor, or controller.

[0074] As is known in the art, the operations described above may be performed by hardware, software, or some combination of software and hardware. Various aspects of the exemplary embodiments may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software) that, when executed by a processor, cause the processor to perform methods that implement the present application. Furthermore, some exemplary embodiments of the present application may be implemented solely in hardware, while other exemplary embodiments may be implemented solely in software. Furthermore, the various functions described may be performed in a single unit or may be distributed across multiple components in any number of ways. When implemented by software, the methods may be executed by a processor, such as a general-purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions may be stored on the medium in compressed and / or encrypted format.

[0075] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings herein. Various aspects and / or components of the described exemplary embodiments may be used alone or in any combination. It is intended that the specification and exemplary embodiments be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims. [Explanation of symbols]

[0076] 605 Computing Devices 610 processor 615 memory 620 Internal Storage 625 I / O interface 635 Input / User Interface 640 Output Devices / Interfaces 645 External Storage 650 Network 660 logical units 665 API units 670 Input Unit 675 output unit

Claims

1. 1. A method for constructing a troubleshooting tree for an instrument, comprising: receiving, in a preprocessing pipeline, an unstructured text source including sections; segmenting the unstructured text source and using a parser to extract a list of respective sections associated with at least one of the components of the equipment, unit, or process; In response to determining that the parser has not completely extracted the list, providing the unstructured text source to a pre-trained language model; instructing the pre-trained language model to identify each section by using the list of sections as a context; For each section, obtaining metadata including section-specific text associated with the unstructured text source and corresponding section titles and page ranges; pre-processing the sections to obtain segmented data by applying a non-static process that increases consistency of similarity matching; using an indexing process that embeds the segmented data and the metadata into index nodes to improve search efficiency in a troubleshooting tree building pipeline; For each component, using the index node of the troubleshooting tree building pipeline: generating a catalog containing faults, causes, or repair recommendations using the pre-trained language model; structuring at least some of the faults, causes, and repair recommendations as nodes of the troubleshooting tree; generating the troubleshooting tree in response to at least one of the equipment, units, or processes being queried by a user query; a rationalization process including cross-referencing at least a portion of the troubleshooting tree with the unstructured text source, and using the metadata in the rationalization process to evaluate the accuracy of the troubleshooting tree; and outputting the troubleshooting tree.

2. The method of claim 1 , wherein one or more of the index nodes comprises preprocessed text data.

3. The method comprises: extracting new text data from the updated unstructured text; generating troubleshooting branches associated with previously unidentified problems using the pre-trained language model; and merging the troubleshooting branch into the troubleshooting tree to obtain an updated troubleshooting tree; 10. The method of claim 1, further comprising validating the troubleshooting tree against new source material to increase accuracy.

4. The method of claim 3 , wherein the troubleshooting tree is structured to facilitate extension and enrichment with data from previously unseen, unstructured text sources.

5. The method of claim 1 , wherein the user query includes a prompt that generates an output including at least one of the component, the fault, the cause, or the repair recommendation for one or more steps.

6. The method of claim 5 , wherein the output is generated as a Python list.

7. The method of claim 1 , wherein the unstructured text source comprises at least one of a service log, a service manual, or an owner's manual.

8. The method of claim 1 , wherein the indexing process comprises database indexing.

9. The method of claim 1 , further comprising instructing the pre-trained language model to identify each section as a separate set of documents.

10. The method of claim 1 , wherein the section-specific text includes a section name.

11. The method of claim 1 , wherein the pre-trained language model uses a search expansion generation process to search for information.

12. The method of claim 11 , wherein the justification process further comprises evaluating the output of the pre-trained language model against a context used to retrieve the information.

13. 12. The method of claim 11, wherein the rationalization process further comprises providing references to one or more of the sections containing information that enables user verification of the accuracy of the troubleshooting tree to improve output accuracy.

14. 1. A non-transitory computer-readable medium for storing instructions for performing a process, the instructions comprising: receiving an unstructured text source containing sections in a preprocessing pipeline; segmenting the unstructured text source and using a parser to extract a list of respective sections associated with at least one of the components of the equipment, unit, or process; In response to determining that the parser has not completely extracted the list, providing the unstructured text source to a pre-trained language model; instructing the pre-trained language model to identify each section by using the list of sections as a context; For each section, obtaining metadata including section-specific text associated with the unstructured text source and corresponding section titles and page ranges; pre-processing the sections to obtain segmented data by applying a non-static process that increases consistency of similarity matching; using an indexing process that embeds the segmented data and the metadata into index nodes to improve search efficiency in a troubleshooting tree building pipeline; For each component, using the index node of the troubleshooting tree building pipeline: generating a catalog containing faults, causes, or repair recommendations using the pre-trained language model; structuring at least some of the faults, causes, and repair recommendations as nodes of a troubleshooting tree; generating the troubleshooting tree in response to at least one of the equipment, units, or processes being queried by a user query; a rationalization process including cross-referencing at least a portion of the troubleshooting tree with the unstructured text source, and using the metadata in the rationalization process to evaluate the accuracy of the troubleshooting tree; and outputting the troubleshooting tree.

15. The non-transitory computer-readable medium of claim 14 , wherein the pre-trained language model employs a search expansion generation process to search for information.

16. 16. The non-transitory computer-readable medium of claim 15, wherein the justification process further comprises evaluating an output of the pre-trained language model against a context used to retrieve the information.

17. 16. The non-transitory computer-readable medium of claim 15, wherein the rationalization process further comprises providing references to one or more sections containing information that enables user verification of the accuracy of the troubleshooting tree to improve output accuracy.

18. 15. The non-transitory computer-readable medium of claim 14, wherein fourteen or more of the index nodes include preprocessed text data.

19. extracting new text data from the updated unstructured text; generating troubleshooting branches associated with previously unidentified problems using the pre-trained language model; and merging the troubleshooting branch into the troubleshooting tree to obtain an updated troubleshooting tree; Validating troubleshooting trees against new source material to improve accuracy; 15. The non-transitory computer-readable medium of claim 14, comprising:

20. 20. The non-transitory computer-readable medium of claim 19, wherein the troubleshooting tree is structured to facilitate extension and enrichment with data from previously unseen, unstructured textual sources.

Images