Defect identification method and device of work order system, and electronic equipment

Abstract

The invention discloses a defect identification method and device for a work order system, and electronic equipment, and relates to the technical field of model identification. The method comprises the following steps: receiving defect description through a work order information interface; analyzing the defect description by utilizing a large language model, and judging whether the defect problem is a target defect type or not; under the condition that the defect problem is the target defect type, generating a defect information text according to the defect description; and outputting the defect information text as an identification result. Compared with the prior art, the defect description input by the user is recognized through the pre-trained large language model, whether the defect description is the target defect type or not is quickly judged, and the defect information text of the problem is generated under the condition that the defect description is judged to be the target defect type. And compared with a manual identification mode, the accuracy and the identification efficiency are improved. The problems that problem recording is not accurate enough and efficiency is low in an existing manual recognition mode are solved.

Description

Technical Field

[0001] The present application relates to the field of model recognition technology, and specifically to a defect recognition method, device, and electronic equipment for a work order system. Background Art

[0002] For the automated work order systems used by some companies, a work order information interface is set up. If users encounter system defects when using the work order system, such as being unable to log in, page crashes, or certain functions being unavailable, they can provide feedback through the work order information interface. Currently, the defect content reported by users is manually guessed and judged whether it is an online problem (referring to technical defects that need to be optimized due to the system platform's own reasons), and then suggestions and solutions are given. This method is biased in people's subjective understanding and judgment, and the retelling of solutions is time-consuming and labor-intensive. As a result, the current manual identification of user defect descriptions is not accurate enough and is inefficient. Summary of the Invention

[0003] In view of this, the present application provides a defect identification method, device, and electronic equipment for a work order system, which can improve the current problem of inaccurate and inefficient problem identification in the process of manually identifying user defect descriptions.

[0004] In a first aspect, the present application provides a defect identification method for a work order system, comprising:

[0005] Receive a defect description through a work order information interface; the defect description is a user's verbal description of a defect problem that occurs during the use of the work order system;

[0006] Analyze the defect description using a large language model to determine whether the defect problem is a target defect type;

[0007] If the defect problem is a target defect type, a defect information text is generated according to the defect description; the defect information text includes identification information of the defect problem, problem name, defect phenomenon, cause, and treatment suggestions;

[0008] The defect information text is output as a recognition result.

[0009] Optionally, the large language model includes a multi-level decision tree for analyzing the defect description and a script program corresponding to the decision logic at each level;

[0010] The method of using a large language model to analyze the defect description and determine whether the defect problem is a target defect type includes: determining the defect description level by level based on the multi-level judgment tree and the script program corresponding to the judgment logic of each level.

[0011] Optionally, the script program based on the multi-level judgment tree and the corresponding judgment logic of each level judges the defect description step by step, including: judging whether there is a lack of description of the defect problem; if so, making a suggestion-type judgment; if not, judging whether the wrong work order is pulled; if so, making a suggestion-type judgment; if not, judging whether it is a consulting problem; if so, making a suggestion-type judgment; if not, judging whether it is a process step defect; if so, making a suggestion-type judgment; if not, judging whether it is a user identity defect; if so, making a suggestion-type judgment; if not, judging whether it is a defect caused by system latency; if so, making a suggestion-type judgment; if not, based on the defect judgment range of different business lines, making a business-specific judgment on the defect description to determine the target defect type of the defect problem.

[0012] Optionally, the suggestion type judgment includes: judging whether the defect description is a functional optimization suggestion for the work order system; if so, judging that the defect problem is the target defect type; if not, judging that the defect problem is not the target defect type.

[0013] Optionally, outputting the defect information text as the recognition result includes: outputting the defect information text to a maintenance system; and / or outputting the defect information text to an operation and maintenance background.

[0014] Optionally, after outputting the defect information text as a recognition result, the method further includes: using the current defect description and the recognition result as historical defect cases to train the large language model.

[0015] Optionally, the work order system includes multiple business lines;

[0016] The training process of the large language model includes: pre-importing the defect judgment range of each business line into the initial model; identifying multiple descriptive texts based on the defect judgment range and historical defect cases of each business line; and training the initial model through the descriptive texts and / or combinations of the descriptive texts to obtain the large language model.

[0017] In a second aspect, the present application provides a defect identification device for a work order system, comprising:

[0018] A receiving unit is configured to receive a defect description through a work order information interface; the defect description is a user's verbal description of a defect problem that occurs during the use of the work order system;

[0019] an analyzing unit configured to analyze the defect description using a large language model to determine whether the defect problem is a target defect type;

[0020] A generating unit is configured to generate a defect information text according to the defect description when the defect problem is a target defect type; the defect information text includes identification information of the defect problem, problem name, defect phenomenon, cause, and treatment suggestions;

[0021] The output unit is configured to output the defect information text as a recognition result.

[0022] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the defect identification method of the work order system described in the first aspect or the second aspect.

[0023] In a fourth aspect, the present application provides an electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein when the processor executes the computer program, the defect identification method of the work order system described in the first aspect or the second aspect is implemented.

[0024] By means of the above technical solution, the present application provides a defect identification method, device, and electronic device for a work order system, which first receives a defect description of a defect problem reported by a user during the use of the system through a work order information interface; then inputs the defect description into a large language model for analysis to determine whether the defect problem is of the target defect type; if it is of the target defect type, a defect information text is generated based on the defect description, and then the defect information text is output. Compared with related technologies, the present application identifies the defect description input by the user through a pre-trained large language model, quickly determines whether it is of the target defect type, and generates a defect information text for the problem if it is determined to be of the target defect type. Compared with manual recognition methods, the accuracy and recognition efficiency are improved. Improves the problem that current manual recognition methods have problems of inaccurate and inefficient problem records.

[0025] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0027] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0028] Figure 1 A schematic diagram of a defect identification method for a work order system provided in an embodiment of the present application is shown;

[0029] Figure 2 A schematic diagram showing a flow chart of another defect identification method for a work order system provided in an embodiment of the present application is shown;

[0030] Figure 3 A structural schematic diagram of a defect identification device of a work order system provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0031] In order to be able to more clearly understand the above-mentioned purposes, features and advantages of the present application, the scheme of the present application will be further described below. It should be noted that, in the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other. In addition, in order to be able to understand the characteristics and technical content of the embodiments of the present disclosure in more detail, the implementation of the embodiments of the present disclosure is described in detail below in conjunction with the accompanying drawings. The accompanying drawings are for reference only and are not used to limit the embodiments of the present disclosure. In the following technical description, for the sake of convenience of explanation, a full understanding of the disclosed embodiments is provided through a plurality of details. However, in the absence of these details, one or more embodiments can still be implemented. In other cases, to simplify the drawings, well-known structures and devices can be simplified for display.

[0032] In order to improve the current problem of inaccurate and inefficient problem identification in the process of manually identifying user defect descriptions, this embodiment proposes a defect identification method for a work order system. Figure 1 As shown, the method includes:

[0033] S101, receiving defect description through the work order information interface.

[0034] A defect description is a user's verbal description of a defect encountered while using the ticket system. For example, if a user encounters problems such as being unable to log in, a page crash, or a function not working, they can report the error through the ticket information interface.

[0035] S102: Analyze the defect description using a large language model to determine whether the defect problem is a target defect type.

[0036] Large language models, also known as large models (short for large language models), not only understand and generate human language but also have very large parameters. Leveraging the high accuracy of large models to classify and identify issues ensures accurate understanding of user defect descriptions and the dissemination of defect information.

[0037] The target defect type can be preset. In this embodiment, it refers to technical defect problems (also called "online problems") that need to be optimized due to the system platform's own reasons. It can include: system defect bugs (including those that are in the process of being processed or have been repaired), product function deficiencies (including those that have not yet been launched in the iteration plan), discovered abnormal scenario problems (including problems caused by dependent parties), and product usability issues (including those that users think are difficult to use or lack necessary guidance).

[0038] For example, questions like "Is the problem caused by a DNS error?" or "Is the problem caused by insufficient public queue resources or system resources?" are common. For these types of issues, users typically describe superficial symptoms, such as a server failure. However, manual analysis alone cannot clearly determine the specific cause of the server failure. Therefore, a large language model capable of incorporating multi-line parameters and multi-level judgment logic is used to improve recognition accuracy and efficiency. Of course, other defect types can also be selected as target defect types.

[0039] The large language model mentioned in this embodiment includes at least three parts during the training phase: importing a functional overview of each functional module, prompting design judgments, and historical ticket chat content. Importing a functional overview of each functional module pre-introduces the defect judgment scope for each business line into the initial model. Prompting design judgments is the result of training with training material, resulting in a multi-level decision tree for analyzing defect descriptions and the judgment logic for each level. Historical ticket chat content represents the descriptive text and combinations of historical defect cases identified for each business line.

[0040] S103: When the defect problem is of the target defect type, generate a defect information text according to the defect description.

[0041] If the defect is determined to be the target defect type, a defect information file is generated based on the defect description. This defect information file can be understood as a file created for the defect, including the defect identification information, problem name, defect symptoms, causes, and treatment suggestions. In actual applications, the defect file can be converted into a defect information card or defect information table.

[0042] Here we use a case study of a defect information text to illustrate this. The defect text information is a defect information card: such as "

[12345] Setting the timed loop is invalid"

[0043] Its format is [work order ID] + [work order problem description]. The work order problem description is also the defect description, which is obtained from the work order information interface. The work order ID is also the identification information, which is automatically generated by the system as 12345.

[0044] After identification through the large language model, the target defect type is determined and a defect information card is generated, such as:

[0045] [Defect phenomenon] After the user's front-end project changes the router, it does not take effect and is redirected to a Jaeger page, where the old router does not take effect.

[0046] [Cause] The user's domain name switch has not been re-published, and the ingress resource has not been enabled or has been deleted.

[0047] [Suggestion] First, turn off the domain name switch before publishing, then turn it on again and publish. After re-publishing twice, the problem is solved.

[0048] [To be resolved] Fix the occasional disappearance of ingress resources"

[0049] The above-mentioned problem phenomena, causes, processing procedures, and items to be resolved are all automatically filled in by the return results after recognition by the large language model, without the need for human resources to obtain them, greatly improving recognition efficiency.

[0050] S104: Output the defect information text as the recognition result.

[0051] It can then be output to operation and maintenance personnel and / or directly to the maintenance system. An audit node can also be generated in subsequent links for the auditors to determine whether the recognition results of the large language model are accurate.

[0052] In this embodiment, first, the defect description of the defect problem reported by the user during the use of the system is received through the work order information interface; then the defect description is input into the large language model for analysis to determine whether the defect problem is the target defect type; if it is the target defect type, a defect information text is generated based on the defect description, and the defect information text includes the identification information of the defect problem, the name of the problem, the defect phenomenon, the cause, the treatment suggestion, etc., and then the defect information text is output. Compared with the related art, this embodiment identifies the defect description input by the user through a pre-trained large language model, quickly determines whether it is the target defect type, and generates the defect information text of the problem if it is determined to be the target defect type. Compared with the manual recognition method, the accuracy and recognition efficiency are improved. Improve the problem that the current problem of inaccurate and inefficient problem recording through manual recognition. Optionally, the work order system includes multiple business lines.

[0053] The training process of the large language model includes: pre-importing the defect judgment range of each business line into the initial model; identifying multiple descriptive texts based on the defect judgment range and historical defect cases of each business line; and training the initial model through the descriptive texts and / or combinations of descriptive texts to obtain the large language model.

[0054] Business lines may include: publishing system-related services; FaaS function platform; big data-platform capabilities, including: development center, publishing center, data query, data quality, data map, data governance, configuration management, and scheduling system; big data-underlying capabilities, including: Spark, Flink, origin, storage, StarRocks; big data-data governance; algorithm platform, supercomputing platform LPAI; account services; application access platform; traffic access; gateway services, etc.

[0055] In this embodiment, the large language model includes a multi-level judgment tree for analyzing defect descriptions and a script program corresponding to the judgment logic at each level. This process is actually a prompt design process for the large language model. First, it is necessary to import the defect judgment range of each business line into the initial model. The reason is that the defect range that can be judged in different business lines and the definition of "online problem" defects may be different. For example, in the application access platform, problems caused by network permissions, network bandwidth, network configuration, network maintenance, network jitter, DNS verification, etc. are usually checked, while the algorithm platform may give priority to problems caused by training data, device performance (graphics card, CPU, memory resources, etc.), task priority, user permissions / IP, etc. Therefore, the defect judgment range of each business line is imported in advance, and the defect description can be subjected to business-specific judgment in the subsequent judgment process to determine whether the defect description is the target defect type. This will improve the recognition accuracy of the model.

[0056] Historical defect cases and multiple description texts refer to the multiple training sets finally generated by the combination of work order basic data, chat content (description text), and chat content, which are used to train the large language model. For example, the description text here may be obtained from historical defect cases, such as the user's description of "the approval OA cannot be sent out", but other historical defect cases may obtain the description text of "the approval OA cannot be sent out and the network is abnormal". These two types of texts can be associated and combined for training to obtain the final trained large language model. The large language model contains a multi-level judgment tree for analyzing the defect description and a script program corresponding to the judgment logic at each level, so as to perform multi-level judgment on the defect description.

[0057] In addition, the format can be uniformly selected to use English input and Json format output to facilitate the standardization of the format. Here are some examples corresponding to the multi-level judgment logic:

[0058] As a ticket analysis system, our goal is to help cloud service teams analyze user defect descriptions and create tickets. We retrieve the data for a ticket. Each ticket contains metadata about the work order and a history of conversations between (sometimes multiple) users (historical defect descriptions). We create tickets based on the information provided in the Work Order Metadata and Work Order Chat History sections. The metadata includes the subject, business line, user, and chat history.

[0059] Judgment logic 1: Input product capability information into the model based on the business line to determine which product / system the problem occurs in

[0060] Decision Logic 2: By analyzing ticket topics and chat history, work instructions are categorized into five categories: problem consultation, troubleshooting, request suggestion, action execution, and functional testing. Problem consultation means the user doesn't fully understand how to interact with the system. Troubleshooting means there's an online issue in the system that needs to be fixed. Request suggestion means the user wants an improvement. Action execution means the user wants the caller to perform a privileged operation. Functional testing means the ticket was created solely to test a feature of the ticketing system and doesn't report any issues.

[0061] Judgment Logic 3: By analyzing the work order chat history (historical defect descriptions), determine which of the following roles the person who ultimately resolves the work order problem belongs to: user, on-duty person, and other collaborators. The on-duty person can be a robot that can be set up in the operation and maintenance backend to determine whether the generated defect information cards are correct and provide guidance, suggestions, and related assistance. Collaborators can be added for human review or participation at certain nodes, such as setting up the work order information interface to receive descriptions of other collaborators in addition to the user.

[0062] Judgment logic 4: Determine whether the problem is caused by the user himself: not knowing how to interact, wrong configuration, data problem, personal network problem, user IP problem, SQL error, code error, incorrect operation, lack of permission, etc.

[0063] Judgment logic 5: Determine whether the problem was solved under the guidance or suggestions of the on-duty person, and whether the user accepted the guidance or suggestions of the on-duty person.

[0064] Judgment logic 6: Determine whether the work order is a normal approval and urging operation.

[0065] Judgment logic 7: Determine whether the work order is a normal resource expansion, file upload, data export, role change, etc.

[0066] Judgment logic 8: Describe the problem phenomenon, whether the cause of the problem is mentioned, what is the cause of the problem, whether the solution is mentioned, and whether the solution process is described.

[0067] Judgment logic 9: Determine whether the cause of the problem is that the system is undergoing normal operations such as iteration, online launch, or restart.

[0068] Judgment logic 10: Determine whether there is a problem that needs to be repaired and scheduled for resolution, and what the problem is.

[0069] Judgment logic 11: Determine whether the work order does not clearly state the cause and solution of the problem and whether further investigation is required.

[0070] Decision 12: Analyze the chat history to determine whether any key information is missing from the ticket. Three types of key information are defined: what the problem is, why the problem occurred, and how to resolve the problem. If one or more of these three types of key information is missing, the ticket is considered missing key information; otherwise, it is not considered missing key information.

[0071] Judgment logic 13: Determine whether the user has selected the wrong work order.

[0072] Decision logic 14: By analyzing the chat history, determine whether the user has raised any missing features of the product, and what the missing features are.

[0073] Decision logic 15: By analyzing the chat history, determine whether this is a suggestion for improving the existing product features. What suggestions are there?

[0074] Optionally, a large language model is used to analyze the defect description to determine whether the defect problem is a target defect type, including: judging the defect description level by level based on a multi-level judgment tree and a script program corresponding to the judgment logic of each level.

[0075] Optionally, the multi-level decision tree includes at least one of the following: determining whether a description of the defect problem is missing;

[0076] Determine whether the work order is pulled incorrectly. If so, make a suggestion judgment; if not, proceed to the next level of judgment;

[0077] Determine whether it is a consultation question. If so, proceed to the next level of judgment; if not, proceed to the next level of judgment;

[0078] Determine whether it is a process step defect. If so, make a suggestion judgment; if not, proceed to the next level of judgment;

[0079] Determine whether it is a user identity defect. If so, make a suggestion judgment; if not, proceed to the next level of judgment;

[0080] Determine whether the defect is caused by system latency. If so, make a recommendation. If not, proceed to the next level of judgment.

[0081] Among them, it is determined whether the description of the defect problem is missing. If so, a suggestion judgment is performed; if not, the next level of judgment is entered. It should be noted that the judgment logic sequence between the above multi-level judgment trees is not limited.

[0082] Furthermore, based on the multi-level judgment tree and the script program corresponding to the judgment logic of each level, the defect description is judged level by level, including: judging whether there is a lack of description of the defect problem; if so, making a suggestion-type judgment; if not, judging whether the wrong work order is pulled; if so, making a suggestion-type judgment; if not, judging whether it is a consulting problem; if so, making a suggestion-type judgment; if not, judging whether it is a process step defect; if so, making a suggestion-type judgment; if not, judging whether it is a user identity defect; if so, making a suggestion-type judgment; if not, judging whether it is a defect caused by system latency; if so, making a suggestion-type judgment; if not, based on the defect judgment scope of different business lines, a business-specific judgment is made on the defect description to determine the target defect type of the defect problem.

[0083] In this embodiment, a multi-level judgment is performed on the defect description input by the user based on the multi-level judgment tree in the trained large language model. The specific judgment process is as follows: Figure 2 As shown:

[0084] First, the first level of judgment is performed to determine whether a description of the defect problem is missing, that is, whether key information is missing. The key issues here can be pre-defined. In this embodiment, "What is the problem?", "Why the problem occurred?", and "How to solve the problem" are defined as key information. If these three types of information are missing, the key information is not clear, that is, the specific defect problem is not clearly stated. If it is missing, the system is judged to be a suggestion for the system (suggestion judgment). If it is not missing, the second level of judgment is performed.

[0085] The second level determines whether the issue was raised incorrectly, meaning the user's submission isn't a bug description, perhaps due to clicking the wrong interface. The third level determines whether the issue is a consulting issue, such as "The user doesn't fully understand how to interact with the system," "There's an online issue in the system that needs fixing," "The user expects improvements," "The user wants to gain access to certain privileged operations," or "Testing a certain system feature." The fourth level determines whether the issue lies within a process step. This includes operations such as normal approval follow-up, resource expansion, file uploads, data exports, and role changes. If these operations fail, it can be considered a system defect within the process step. The fifth level determines whether the issue lies within the user's identity, including issues with user configuration, SQL, code, operations, permissions, and the network. The sixth level determines whether the defect is caused by system latency, such as a "system release / restart" error, or a missing product feature (e.g., if the user mentions a missing product feature in the bug description, whether they provide improvement suggestions, and what type of improvement suggestions they provide).

[0086] In one feasible embodiment, identities can also be defined, for example, by defining three roles: user, on-duty person, and collaborator. The on-duty person can be a robot that can be deployed in the maintenance backend to determine the correctness of generated defect information cards and provide guidance, suggestions, and other assistance. Collaborators can be added to certain nodes for human review or participation, such as by allowing the work order information interface to receive descriptions of collaborators in addition to the user.

[0087] If the first six levels of judgment are all negative, and the defect is not caused by the above problems, the seventh level of judgment is performed, and judgment is made by business line-specific logic. Here, the defect judgment range of each business line is determined by the pre-imported defect judgment range, for example:

[0088] Application access platform:

[0089] 1. Is the problem caused by network permission restrictions (yes / no)

[0090] 2. Is the problem caused by insufficient network bandwidth? (Yes / No)

[0091] 3. Is the problem resolved by changing the network configuration or adjusting the network policy (yes / no)?

[0092] 4. Is the problem occurring during network maintenance? (Yes / No)

[0093] 5. Is the problem caused by network jitter or a third-party supplier? (Yes / No)

[0094] 6. Is the problem caused by DNS? (Yes / No)

[0095] Account Services:

[0096] 1. Is it caused by network problems? (Yes / No)

[0097] 2. Is it the issue with test / ontest / testtwo / testone not receiving the SMS verification code? (Yes / No)

[0098] 3. Is it a database connection timeout problem (yes / no)

[0099] 4. Is the pod status abnormal? (Yes / No)

[0100] Algorithm platform:

[0101] 1. Is it due to problems with the training data? (Yes / No)

[0102] 2. Is the problem caused by a problem with the training machine / graphics card / GPU / CPU / memory or insufficient resources / quota? (Yes / No)

[0103] 3. Is it caused by the user's image / permission / browser / PN / network / IP problem (yes / no)?

[0104] 4. Is it a task priority queuing issue (yes / no)

[0105] 5. Is the problem solved by capacity expansion? (Yes / No)

[0106] 6. Is it caused by a problem with the github / conda / pip source? '(yes / no)

[0107] Big Data:

[0108] 1. Is this due to a shortage of public queue resources? (Yes / No)

[0109] 2. Is it due to insufficient system resources? (Yes / No)

[0110] 3. Is the problem caused by exceeding system limits? (Yes / No)

[0111] 4. Is the problem caused by the user's browser? (Yes / No)

[0112] 5. Is the problem solved by adding more memory? (Yes / No)

[0113] 6. Was the issue resolved by adjusting permissions? (Yes / No)

[0114] Release system related:

[0115] 1. Is it caused by network problems? (Yes / No)

[0116] 2. Is this caused by a problem with the user's Dockerfile? (Yes / No)

[0117] 3. Is this caused by a problem with the GitHub / Pip source? (Yes / No)

[0118] 4. Is the problem caused by insufficient resources? (Yes / No)

[0119] 5. Is the problem caused by a locked account? (Yes / No)

[0120] Optionally, a suggestion type judgment is performed, including: judging whether the defect description is a functional optimization suggestion for the work order system; if so, determining that the defect problem is a target defect type; if not, determining that the defect problem is not a target defect type.

[0121] In this embodiment, if any of the first six levels of judgments yields a positive result, the current defect description does not clearly reflect the system's existing defect problem, but may instead provide direct functional optimization suggestions for the system, such as "fixing the occasional disappearance of ingress resources." This type of problem can also be identified as an online issue and recorded. This multi-level judgment effectively improves recognition accuracy compared to manual analysis.

[0122] Optionally, outputting the defect information text as the recognition result includes: outputting the defect information text to a maintenance system; and / or outputting the defect information text to an operation and maintenance background.

[0123] In this embodiment, the defect information text can be subsequently output to the operation and maintenance personnel and / or directly output to the maintenance system to facilitate repair processing. An audit node can also be generated in the subsequent link, and the auditor will determine whether the recognition result of the large language model is accurate.

[0124] Optionally, after outputting the defect information text as the recognition result, the method further includes: using the current defect description and the recognition result as historical defect cases to train the large language model.

[0125] In this embodiment, the learning model is continuously optimized based on user feedback and historical defect cases, thereby improving the high accuracy of the large model and ensuring that the defect description work order is correctly understood and distributed.

[0126] Combined with the solutions proposed in the above embodiments, the solutions proposed in this embodiment have the following technical advantages: Improved efficiency: The system can automatically process and analyze defect work orders, significantly reduce manpower input and processing time, and speed up the turnover of work orders. Enhanced accuracy: Through the large language model, the system can reduce the errors that may be caused by manual analysis and improve the accuracy of work order processing. Reduced costs: With the improvement of the degree of automation, labor costs can be reduced, while improving the cost-effectiveness of the entire processing flow. Improved user experience: By handling problems quickly and accurately, user satisfaction and trust can be improved, and the user experience can be optimized. Dynamic optimization: The large model can continuously learn and optimize with new data, so that the system can continue to improve its performance over time and accumulated data.

[0127] Further, as Figure 1 and Figure 2 The specific implementation of the method shown in this embodiment provides a defect identification device for a work order system, such as Figure 3 As shown, the device includes: a receiving unit 301, an analyzing unit 302, a generating unit 303 and an output unit 304.

[0128] The receiving unit 301 is configured to receive a defect description through a work order information interface; the defect description is a user's verbal description of a defect problem that occurs during the use of the work order system;

[0129] An analyzing unit 302 is configured to analyze the defect description using a large language model to determine whether the defect problem is a target defect type;

[0130] The generating unit 303 is configured to generate a defect information text according to the defect description when the defect problem is a target defect type; the defect information text includes identification information of the defect problem, problem name, defect phenomenon, cause, and treatment suggestion;

[0131] The output unit 304 is configured to output the defect information text as a recognition result.

[0132] In a specific application scenario, the analyzing unit 302 is specifically configured to perform level-by-level judgment on the defect description based on the multi-level judgment tree and the script program corresponding to the judgment logic of each level.

[0133] In a specific application scenario, the analysis unit 302 is further configured to determine whether there is a lack of description of the defect problem; if so, perform a suggestion-type judgment; if not, determine whether the wrong work order is pulled; if so, perform a suggestion-type judgment; if not, determine whether it is a consulting-type problem; if so, perform a suggestion-type judgment; if not, determine whether it is a process step defect; if so, perform a suggestion-type judgment; if not, determine whether it is a user identity defect; if so, perform a suggestion-type judgment; if not, determine whether it is a defect caused by system latency; if so, perform a suggestion-type judgment; if not, based on the defect judgment range of different business lines, perform a business-specific judgment on the defect description to determine the target defect type of the defect problem.

[0134] In a specific application scenario, the analysis unit 302 is further configured to determine whether the defect description is a functional optimization suggestion for the work order system. If so, the defect problem is determined to be the target defect type; if not, the defect problem is determined not to be the target defect type.

[0135] In a specific application scenario, the output unit 304 is further configured to output the defect information text to a maintenance system; and / or output the defect information text to an operation and maintenance backend.

[0136] In a specific application scenario, the output unit 304 is further configured to use the current defect description and recognition result as a historical defect case to train the large language model.

[0137] It should be noted that for other corresponding descriptions of the various functional units involved in the defect identification device of the work order system provided in this embodiment, please refer to Figure 1 and Figure 2 The corresponding description in will not be repeated here.

[0138] Based on the above Figure 1 and Figure 2 The method shown in FIG. 1 is a method for performing the above-mentioned steps. Accordingly, this embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program can realize the above-mentioned steps. Figure 1 and Figure 2 The method shown.

[0139] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0140] Based on the above Figure 1 and Figure 2 The method shown, and Figure 3 In order to achieve the above-mentioned purpose, the embodiment of the present application further provides an electronic device that can be configured on a computer terminal, etc. The device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 and Figure 2 The method shown.

[0141] Optionally, the physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, etc. The user interface may include a display, an input unit such as a keyboard, etc., and may optionally include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc.

[0142] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0143] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.

[0144] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus the necessary general hardware platform, or by hardware. When applying the solution of this embodiment, first, the defect description of the defect problem reported by the user during the use of the system is received through the work order information interface; then the defect description is input into the large language model for analysis to determine whether the defect problem is the target defect type; if it is the target defect type, a defect information text is generated based on the defect description, and then the defect information text is output. Compared with the relevant technology, this embodiment identifies the defect description input by the user through a pre-trained large language model, quickly determines whether it is the target defect type, and generates the defect information text of the problem if it is determined to be the target defect type. Compared with the manual recognition method, the accuracy and recognition efficiency are improved. Improve the problem that the current problem of inaccurate and inefficient problem records through manual recognition is improved.

[0145] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprises" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a..." do not exclude the presence of other identical elements in the process, method, article or device that includes the elements.

[0146] The above description is only a specific embodiment of the present application, which enables those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features of the present application.

[0147] The above description and accompanying drawings sufficiently illustrate the embodiments of the present disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, process, and other changes. The embodiments represent only possible variations. Unless expressly required, individual components and functions are optional, and the order of operations may vary. Portions and features of some embodiments may be included in or replaced with portions and features of other embodiments. As used in this application, the term "and / or" means including any and all possible combinations of one or more associated listed items. In addition, when used in this application, the term "comprise" and its variations "comprises" and / or comprising refer to the presence of the stated features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof. Without further limitation, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or device that includes the element. In this document, each embodiment may focus on the differences from other embodiments, and similar parts between the embodiments can be referenced. For methods, devices, etc. disclosed in the embodiments, if they correspond to the method part disclosed in the embodiments, then the relevant parts can be referenced in the description of the method part.

[0148] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software may depend on the specific application and design constraints of the technical solution. The technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present disclosure. The technicians will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0149] In the embodiments disclosed herein, the disclosed methods and products (including but not limited to devices, equipment, etc.) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units can be merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between each other shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, and can be electrical, mechanical or other forms. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of the present disclosure may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0150] The flowcharts and block diagrams in the accompanying drawings show the possible implementation architectures, functions and operations of the systems, methods and computer program products according to the embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of the code, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different boxes can also occur in an order different from that disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action, or may be implemented by a combination of dedicated hardware and computer instructions.

Claims

1. A defect identification method for a work order system, characterized in that: include: Receive defect descriptions through the work order information interface; The defect description is a user's verbal description of a defect problem that occurs during the use of the work order system; Analyze the defect description using a large language model to determine whether the defect problem is a target defect type; In the case where the defect problem is a target defect type, generating a defect information text according to the defect description; The defect information text is output as a recognition result.

2. The method according to claim 1, characterized in that The large language model includes a multi-level judgment tree for analyzing the defect description and a script program corresponding to the judgment logic of each level; The use of a large language model to analyze the defect description and determine whether the defect problem is a target defect type includes: Based on the multi-level judgment tree and the script program corresponding to the judgment logic of each level, the defect description is judged level by level.

3. The method according to claim 2, characterized in that The step of judging the defect description level by level based on the multi-level judgment tree and the script program corresponding to each level of judgment logic includes: Determine whether there is a lack of description of the defect problem; if so, make a suggestion judgment; if not, Determine whether the work order is pulled incorrectly; if so, make a suggestion; if not, Determine whether it is a consulting question; if so, make a suggestion; if not, Determine whether it is a process step defect; if so, make a suggestion judgment; if not, Determine whether it is a user identity defect; if so, make a suggestion judgment; if not, Determine whether the defect is caused by system latency; if so, make a recommendation; if not, Based on the defect judgment scope of different business lines, a business-specific judgment is made on the defect description to determine the target defect type of the defect problem.

4. The method according to claim 3, characterized in that The making of suggestion judgment includes: Determine whether the defect description is a functional optimization suggestion for the work order system. If so, determine that the defect problem is the target defect type; if not, determine that the defect problem is not the target defect type.

5. The method according to claim 1, wherein Outputting the defect information text as a recognition result includes: Outputting the defect information text to a maintenance system; and / or, Output the defect information text to the operation and maintenance background.

6. The method according to claim 1, wherein After outputting the defect information text as the recognition result, the method further includes: The defect description and identification results of this time are used as historical defect cases to train the large language model.

7. The method according to claim 1, characterized in that The work order system includes multiple business lines; The training process of the large language model includes: Import the defect judgment scope of each business line into the initial model in advance; Based on the defect judgment scope and historical defect cases of each business line, multiple description texts are identified; The initial model is trained using the description text and / or a combination of the description texts to obtain the large language model.

8. A defect identification device for a work order system, characterized in that: include: The receiving unit is configured to receive a defect description through a work order information interface; The defect description is a user's verbal description of a defect problem that occurs during the use of the work order system; an analyzing unit configured to analyze the defect description using a large language model to determine whether the defect problem is a target defect type; A generating unit configured to generate a defect information text according to the defect description when the defect problem is a target defect type; The defect information text includes the identification information of the defect problem, the problem name, the defect phenomenon, the cause, and the treatment suggestions; The output unit is configured to output the defect information text as a recognition result.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

10. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 5 is implemented.

Images