Data processing method, electronic device, and storage medium

Abstract

The application discloses a data processing method, an electronic device and a storage medium, wherein the method comprises: acquiring multi-source data of a newly created target problem; the multi-source data comprises problem data and attachment data, and the problem data comprises a problem description; searching a historical case database according to the problem description to obtain a historical reference result; identifying abnormal information in the attachment data to obtain an attachment check result; determining a target analysis unit sequence associated with the problem description from the attachment data, and determining an attachment analysis result set according to the target analysis unit sequence; inputting the historical reference result, the attachment check result, the attachment analysis result set and the problem description into a multi-model cooperative judgment device to output a first analysis conclusion; and writing the first analysis conclusion back to the target problem.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a data processing method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In the software development lifecycle, Jira, as a mainstream issue tracking tool, is widely used in scenarios such as defect management, task assignment, and fault logging. When dealing with newly reported Jira issues, developers, operations, and testers typically need to manually retrieve multi-dimensional information such as issue descriptions, attached logs, historical comments, and status transition records, filter key clues line by line, review historical tickets to find similar cases, and then combine their personal experience to deduce the root cause and formulate solutions.

[0003] However, the relevant technical solutions have the following shortcomings: A single Jira issue ticket contains lengthy text descriptions, and log attachments are voluminous and fragmented, requiring engineers to manually screen and carefully read them for hours, resulting in slow response times in emergency scenarios; the root cause summaries and solutions contained in the massive amount of closed-loop historical issues accumulated by the enterprise are scattered and stored in independent issue tickets, lacking structured and semantic management methods, leading engineers to rely on personal memory to retrieve cases, resulting in a large amount of valuable experience being idle; manual analysis of attachments such as logs and stack traces is inefficient, making it difficult to quickly match issue descriptions with abnormal attachment fragments, easily overlooking key investigation clues; the comprehensiveness and accuracy of issue analysis highly depend on the individual technical level and experience of the handling engineer, with significant differences in analysis results among different engineers for the same issue. Therefore, how to automatically acquire multi-source data, perform semantic understanding and fusion analysis, and generate actionable conclusions has become an urgent problem to be solved. Summary of the Invention

[0004] One objective of this application is to provide a new technical solution for data processing.

[0005] According to a first aspect of this application, a data processing method is provided, comprising: Acquire multi-source data for the newly created target problem; the multi-source data includes problem data and attachment data, and the problem data includes a problem description. Based on the problem description, retrieve historical case databases to obtain historical reference results; Identify abnormal information in the attachment data to obtain the attachment inspection results; Determine the sequence of target parsing units associated with the problem description from the attached data, and determine the set of attached analysis results based on the sequence of target parsing units; The historical reference results, the attachment inspection results, the attachment analysis results set, and the problem description are input into the multi-model collaborative judgment device, and the first analysis conclusion is output. The first analytical conclusion is then written back to the target problem.

[0006] Optionally, the step of retrieving historical case databases based on the problem description to obtain historical reference results includes: Convert the problem description into a problem semantic vector; Based on the semantic similarity between the problem semantic vector and each knowledge entry in the historical case database, a first number of resolved historical cases are selected from the historical case database as a candidate historical case set. Reference historical cases are selected from the candidate historical case set as historical reference results.

[0007] Optionally, identifying abnormal information in the attachment data and obtaining the attachment inspection result includes: If the amount of data in the attachment data is greater than or equal to the data volume threshold, candidate attachment fragments are selected from the attachment data using a preset filtering method. The candidate attachment fragment is divided into multiple parsing units; For any parsing unit, identify whether there is abnormal information in the parsing unit, and obtain the identification result corresponding to the parsing unit; The attachment inspection result is determined based on the identification results corresponding to the multiple parsing units.

[0008] Optionally, determining the target parsing unit sequence associated with the problem description from the attachment data, and determining the attachment analysis result set based on the target parsing unit sequence, includes: If the amount of data in the attachment data is greater than or equal to the data volume threshold, candidate attachment fragments are selected from the attachment data using a preset filtering method. The candidate attachment fragment is divided into multiple parsing units, and the multiple parsing units are vectorized to obtain multiple parsing unit vectors; Based on the semantic similarity between the semantic vector corresponding to the problem description and the plurality of parsing unit vectors, a second number of target parsing units are selected from the plurality of parsing unit vectors to obtain a target parsing unit sequence. If the total text volume of the target parsing unit sequence is greater than the threshold of the model input text volume, the target parsing unit sequence is divided into multiple sub-parsing units; Input each of the multiple sub-parsing units, the problem description, the historical reference results, and the attachment check results into the large language model, and output the contribution analysis results corresponding to the sub-parsing unit; The set of appendix analysis results is obtained based on the contribution analysis results corresponding to the multiple sub-analysis units.

[0009] Optionally, the step of inputting the historical reference results, the attachment inspection results, the attachment analysis result set, and the problem description into the multi-model collaborative analysis device, and outputting the first analysis conclusion, includes: The historical reference results, the attachment inspection results, the attachment analysis results, and the problem description are combined into a comprehensive prompt word, which is then input into at least two dedicated sub-models to obtain the output results corresponding to the at least two dedicated sub-models respectively; the dedicated sub-model includes one of the code logic analysis model, the operation and maintenance architecture analysis model, and the diagnostic pattern matching model. The first analytical conclusion is determined based on the output results of the at least two specialized sub-models.

[0010] Optionally, after writing back the first analysis conclusion to the target problem, the method further includes: Check if there is any new feedback information regarding the target issue; the feedback information includes engineer comments, status changes, and newly added attachments. If new feedback information is detected regarding the target issue, based on the feedback information and the first analysis conclusion, it is determined whether the feedback information is valid: If the feedback information is valid, the first analysis conclusion is updated based on the valid feedback information to obtain the second analysis conclusion. Add the second analytical conclusion to the target problem.

[0011] Optionally, the historical case database is constructed through the following steps: Obtain the historical issue database corresponding to the target project scope; According to preset rules, candidate historical questions are selected from the historical question database to obtain a candidate historical question set; For each candidate historical problem in the candidate historical problem set, based on the root cause summary and solution of the candidate historical problem, the attached data of the candidate historical problem is analyzed, and the related event fragments corresponding to the candidate historical problem are extracted. Based on the metadata of the candidate historical questions and the associated event fragments, the knowledge entries corresponding to the candidate historical questions are determined, and the knowledge entry set corresponding to the candidate historical question set is obtained; Based on multiple knowledge entries belonging to the same type of problem in the knowledge entry set, determine the diagnostic pattern of the problem type; Based on the knowledge entries and metadata of the candidate historical problems, and the diagnostic modes to which the candidate historical problems belong, construct a vector database and a vector library index for the candidate historical problems; Based on the technical entities in the knowledge entry set and the semantic relationships between them, a knowledge graph is constructed. The historical case database is constructed based on the vector database and the knowledge graph.

[0012] Optionally, the method further includes: Obtain the updated historical issue database corresponding to the target project; For each new historical question in the updated historical question database, a corresponding new knowledge entry is generated, resulting in a set of new knowledge entries; For the first type of knowledge entries in the newly added knowledge entry set, the first type of knowledge entries are associated with the corresponding diagnostic patterns; wherein, the first type of knowledge entries are knowledge entries that can be matched with diagnostic patterns in the historical case database; For the second category of knowledge entries in the newly added knowledge entry set, the corresponding diagnostic pattern is determined based on multiple new knowledge entries belonging to the same type of problem in the second category of knowledge entries; wherein, the second category of knowledge entries are knowledge entries that cannot be matched with a diagnostic pattern in the historical case database; Based on the knowledge entries and metadata of the new historical problem, as well as the diagnostic pattern of the new historical problem, determine the vector library index of the new historical problem; The knowledge graph is updated based on the newly added technical entities and semantic relationships in the newly added knowledge entry set, resulting in an updated knowledge graph.

[0013] According to a second aspect of the present invention, an electronic device is provided, including a memory and a processor, the memory being configured to store computer instructions, and the processor being configured to invoke the computer instructions from the memory to perform the method as described in the first aspect.

[0014] According to a third aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0015] According to one embodiment of this disclosure, the technical solution achieves fully automated intelligent analysis of the target problem. By integrating semantic retrieval of the problem description, global anomaly scanning of attachments, and in-depth analysis of key fragments, and combining these three with a multi-model collaborative analyzer, structured root cause localization and solutions can be obtained. This method effectively solves the problems of information overload, difficulty in reusing experience, superficial attachment analysis, and reliance on personal experience in traditional manual analysis. Experiments show that the initial analysis time can be reduced from several hours to several minutes, significantly improving the efficiency of problem processing and the consistency and reliability of conclusions.

[0016] Other features and advantages of this application will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

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

[0018] Figure 1 This is a block diagram of the hardware configuration of an electronic device for implementing a data processing method according to an embodiment of this application.

[0019] Figure 2 This is a schematic flowchart of a data processing method according to an embodiment of this application. Detailed Implementation

[0020] Various exemplary embodiments of the present application will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present application.

[0021] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the scope of this application and its application or use.

[0022] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0023] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0024] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0025] Figure 1 This is a block diagram of the hardware configuration of an electronic device for implementing a data processing method according to an embodiment of this application.

[0026] Electronic device 1000 can be a terminal or a server. Furthermore, the terminal can be a portable computer, tablet computer, handheld computer, etc. The server can be a cloud server, etc.

[0027] Electronic device 1000 may include a processor 1100, a memory 1200, an interface device 1300, a communication device 1400, a display device 1500, an input device 1600, a speaker 1700, a microphone 1800, etc. The processor 1100 may be a central processing unit (CPU), a microprocessor (MCU), etc. The memory 1200 may include, for example, ROM (Read-Only Memory), RAM (Random Access Memory), or non-volatile memory such as a hard disk. The interface device 1300 may include, for example, a USB interface, a headphone jack, etc. The communication device 1400 may be capable of wired or wireless communication. The display device 1500 may be, for example, an LCD screen, a touch screen, etc. The input device 1600 may include, for example, a touch screen, a keyboard, etc. Users can input / output voice information through the speaker 1700 and the microphone 1800.

[0028] Despite Figure 1 The electronic device 1000 shows multiple devices, but this application may only involve some of them. For example, electronic device 1000 may only involve memory 1200 and processor 1100.

[0029] In the embodiments applied in this application, the memory 1200 of the electronic device 1000 is used to store instructions for controlling the processor 1100 to execute the data processing method provided in the embodiments of this application.

[0030] In the above description, those skilled in the art can design instructions based on the scheme disclosed in this application. How the instructions control the processor to operate is well known in the art, and therefore will not be described in detail here.

[0031] Figure 2 This is a flowchart illustrating a data processing method according to an embodiment of this application (the method can be applied to a project management platform), specifically by... Figure 1 The processor 1100 of the electronic device 1000 in the device executes.

[0032] according to Figure 2 As shown, the data processing method of this embodiment may include the following steps S210~S270.

[0033] Step S210: Obtain multi-source data for the newly created target problem; the multi-source data includes problem data and attachment data, and the problem data includes a problem description.

[0034] In this embodiment, the target issue refers to a defect, abnormal work order, regression issue, etc., newly submitted by the user on the project management platform. The project management platform will assign a unique identifier, i.e., an issue identifier, to each newly created target issue.

[0035] Problem data refers to text-based data directly related to the target problem. Problem data includes: problem title ("500 error occurred when calling the system interface"), problem description (details of the problem submitted by the user, including the abnormal phenomenon, the scenario, and the steps taken), related comments (discussions by R&D and testing personnel regarding the problem), solutions (the solutions entered after the problem is resolved, such as "restart the database service, adjust the connection pool parameter to 50"), root cause summary, status change record (the change trajectory of the problem from "pending" to "processing"), personnel information (submitter, processor, commenter, etc.), and environment information (operating system version, device model, operating environment, deployment environment (e.g., code branch).

[0036] Attachment data refers to supplementary files related to the target problem that users upload to the project management platform. Attachment data can include log data, as well as other types of attachments such as screenshots and videos; there are no limitations here. Log data is the core evidence for analyzing the target problem. Log data can include runtime logs (such as Tomcat logs, Nginx logs), application logs (such as Java application logs, Python application logs), database logs (such as MySQL logs), etc. These logs typically contain key fault clues such as exception stack traces, error codes, and module call information. Screenshots, videos, and other attachments can have their text information extracted through OCR recognition, frame extraction analysis, etc., to assist in fault localization using log data.

[0037] By calling the standard API interface provided by the project management platform, the problem data and attachment data of the target problem are obtained in an event-driven manner (i.e., triggered when a new problem is created), ensuring the real-time nature of the data and avoiding the omission of key information.

[0038] Step S220: Retrieve historical case database based on problem description to obtain historical reference results.

[0039] In this embodiment, the historical case database stores closed-loop and verified historical defect and anomaly cases on the project management platform. Each historical case corresponds to a knowledge entry. A knowledge entry is the smallest knowledge unit in the historical case database, and a single knowledge entry corresponds to a closed-loop and verified historical case. This knowledge entry includes a joint vector of text such as the historical case's problem identifier, problem description, root cause summary, solution, and diagnostic pattern.

[0040] This step does not rely on attachment data; it retrieves historical cases solely based on the problem description, avoiding redundant attachments and eliminating invalid historical cases that are semantically similar but do not match the scenario through a large language model, thus solving the problems of mismatch and missed match in traditional keyword retrieval.

[0041] In one embodiment of this application, step S220 retrieves historical case databases based on the problem description to obtain historical reference results, including steps S220.1 to S220.3.

[0042] Step S220.1: Convert the problem description into a problem semantic vector.

[0043] In this embodiment, a text embedding model is used to transform the textual information describing the problem into a high-dimensional semantic vector. The semantic vector can be, for example, a 512-dimensional high-dimensional floating-point array, which can digitally retain the core semantics of the text and eliminate matching bias caused by differences in textual expression.

[0044] Text embedding models can be, for example, the BGE-M3 model.

[0045] In another example, the question title and question description can be concatenated into a text block, which can then be converted into a question semantic vector using a text embedding model.

[0046] Step S220.2: Based on the semantic similarity between the problem semantic vector and each knowledge entry in the historical case database, select a first number of solved historical cases from the historical case database as a candidate historical case set.

[0047] In this embodiment, the similarity between the semantic vector of the target question and all stored knowledge entries in the historical case database is calculated.

[0048] In one example, based on the cosine similarity or dot product between the problem's semantic vector and each knowledge entry in the historical case database, the first number of solved knowledge entries that are closest in distance in the vector space are identified. These knowledge entries represent solved historical cases that are semantically most similar to the target problem.

[0049] For example, the first number can be, for instance, 10. By traversing all knowledge entries in the historical case database, the cosine similarity between the knowledge entry vector and the question semantic vector of the target question is calculated one by one. The results are sorted from high to low scores, and the top 10 solved, non-tested, and non-repeating historical cases are selected to form a candidate historical case set.

[0050] Step S220.3: Select a reference historical case from the candidate historical case set as the historical reference result.

[0051] In this embodiment, a large language model is invoked to evaluate the practicality of each candidate historical case in the candidate historical case set.

[0052] The practicality assessment is a multi-dimensional verification of the authenticity and adaptability of candidate cases. The core verification dimensions include business module consistency, system version adaptability, fault scenario matching degree, and solution feasibility. It is used to filter out false positive candidate historical cases that are "semantically similar but actually unrelated".

[0053] The practicality assessment may include: determining whether the candidate historical case has practical reference value, determining whether the solution of the candidate historical case is applicable to the target problem, and assessing the relevance and reliability of the candidate historical case.

[0054] Based on the utility evaluation results of each candidate historical case in the candidate historical case set, obviously irrelevant candidate historical cases are removed from the candidate historical case set, and the remaining candidate historical cases constitute the historical reference results.

[0055] Step S230: Identify abnormal information in the attachment data and obtain the attachment inspection results.

[0056] In this embodiment, the instruction large language model does not refer to the problem description, but only identifies all abnormal information in the attached data of the target problem and generates attached inspection results. The abnormal information includes anomaly stacks, error modes, and potential risks. Error modes are fixed error reporting patterns of similar faults accumulated over time. Potential risks are implicit configuration, resource, and link vulnerabilities that may not have explicit error reports but are prone to causing faults.

[0057] In one embodiment of this application, step S230, which identifies abnormal information in the attachment data and obtains the attachment inspection result, includes steps S230.1 to S230.4.

[0058] Step S230.1: If the amount of data in the attachment data is greater than or equal to the data amount threshold, candidate attachment fragments are selected from the attachment data using a preset filtering method.

[0059] In this embodiment, the amount of data in the attachment is first determined. If the amount of data is less than the data amount threshold, the entire attachment data is taken as a candidate attachment fragment, and step S230.2 is executed to divide the candidate attachment fragment into multiple parsing units.

[0060] If the data volume is greater than or equal to the data volume threshold, the attachment data is a large attachment. In this case, a preset filtering method is executed to remove invalid attachment fragments from the attachment data and extract candidate attachment fragments containing fault characteristics from the attachment data, which greatly reduces the computing power consumption of subsequent analysis.

[0061] The data volume threshold is a preset critical value, such as 100MB, used to distinguish between regular small attachments and ultra-large redundant attachments.

[0062] The default filtering method is a multi-dimensional noise reduction method, including log level filtering (e.g., retaining ERROR / WARN and removing INFO / DEBUG), error code regular expression matching (e.g., matching keywords such as 500, timeout, and connection exhaustion), and timestamp filtering (e.g., only retaining logs from the time the fault occurred).

[0063] Step S230.2: Divide the candidate attachment fragment into multiple parsing units.

[0064] In this embodiment, if in-depth analysis of candidate attachment fragments is required, an intelligent text segmentation strategy (e.g., by time window, log session, or fixed size) is used to divide the candidate attachment fragments into multiple semantically complete parsing units.

[0065] Each parsing unit is an independent processing unit (such as a line of log or a continuous event segment).

[0066] By performing text chunking on candidate attachment fragments, the parsing unit can be adapted to the single input length limit of a large language model, ensuring that the content of each parsing unit can be parsed independently.

[0067] For example, the 15MB candidate attachment fragment is split into 9 semantically complete and context-coherent independent parsing units based on a single interface exception session.

[0068] Step S230.3: For any parsing unit, identify whether there is abnormal information in the parsing unit, and obtain the identification result corresponding to the parsing unit.

[0069] In this embodiment, the parsing unit is input into a large language model for analysis. The large language model can identify abnormal information based solely on the content of the parsing unit, without referring to the problem description.

[0070] Continuing with the example above, the large language model parses the nine parsing units block by block. In block 6, it identifies database connection exhaustion and explicit SQL timeout anomalies, matches high-frequency resource exhaustion error patterns, and identifies potential risks such as insufficient thread pool configuration and lack of interface rate limiting.

[0071] Step S230.4: Determine the attachment inspection result based on the identification results corresponding to the plurality of parsing units respectively.

[0072] In this embodiment, the identification results of each parsing unit are merged and deduplicated to form a complete attachment inspection result.

[0073] Based on steps S230.1 to S230.4, by using preset filtering methods and segmentation operations, the accuracy of the large language model in identifying abnormal information in each parsing unit can be improved.

[0074] Step S240: Determine the target parsing unit sequence associated with the problem description from the attachment data, and determine the attachment analysis result set based on the target parsing unit sequence.

[0075] In one embodiment of this application, step S240 determines the target parsing unit sequence associated with the problem description from the attachment data, and determines the attachment analysis result set based on the target parsing unit sequence, including steps S240.1 to S240.6.

[0076] Step S240.1: If the amount of data in the attachment data is greater than or equal to the data amount threshold, candidate attachment fragments are selected from the attachment data using a preset filtering method.

[0077] This step is basically the same as the content described in step S230.1 above, and will not be elaborated here.

[0078] Step S240.2: Divide the candidate attachment fragment into multiple parsing units, and vectorize the multiple parsing units to obtain multiple parsing unit vectors.

[0079] In this embodiment, the candidate attachment fragment is first divided into multiple parsing units, which can be referred to the content of step S230.2 above, and will not be elaborated here.

[0080] Then, the high-dimensional vector generated by the text embedding model through the parsing unit is called the parsing unit vector. This parsing unit vector has the same dimension as the question semantic vector, and similarity comparison can be performed directly.

[0081] Step S240.3: Based on the semantic similarity between the problem semantic vector corresponding to the problem description and the multiple parsing unit vectors, select a second number of target parsing units from the multiple parsing unit vectors to obtain the target parsing unit sequence.

[0082] In this embodiment, the semantic similarity (e.g., cosine similarity) between each parsing unit vector and the question semantic vector corresponding to the question description is calculated. The second number of parsing units with the highest similarity is selected as the target parsing units. Irrelevant noise parsing units are eliminated, and a sequence of target parsing units sorted from largest to smallest semantic similarity is generated.

[0083] The second quantity could be, for example, 20, etc., and is not limited here.

[0084] Step S240.4: If the total text volume of the target parsing unit sequence is greater than the threshold of the model input text volume, the target parsing unit sequence is divided into multiple sub-parsing units.

[0085] In this embodiment, when the total text volume of the target parsing unit sequence exceeds the model input text volume threshold, a semantic segmentation strategy is adopted to split the target parsing unit sequence into multiple semantically complete and balanced sub-parsing units. This enables the large language model to perform block-by-block analysis of sub-parsing units while ensuring the integrity of the context. The model input text volume threshold can be the maximum text token threshold that the large language model can accept in a single input, used to avoid errors caused by exceeding the input limit.

[0086] Step S240.5: Input each of the multiple sub-parsing units, the problem description, the historical reference results, and the attachment check results into the large language model, and output the contribution analysis results corresponding to the sub-parsing unit.

[0087] In this embodiment, the core of this step is multi-dimensional cross-validation. Specifically, a sub-parse unit, the problem description, historical reference results, and attachment check results are integrated and input into the large language model. The large language model outputs the value and direct evidence of this sub-parse unit for verifying the hypothesis, as the contribution analysis result.

[0088] During this process, the large language model performs three types of checks: first, it determines whether the root cause summary in the historical reference results is semantically conflicting or unrelated to the anomaly of the sub-parsing unit; second, it determines whether there are any omissions in the attachment check results that are not mentioned in the problem description; and third, it determines whether the sub-parsing unit can confirm or disprove the relevant assumptions generated by the large language model based on the historical reference results and attachment check results (e.g., "database connection pool exhaustion may cause timeout").

[0089] After performing these three checks, the large language model outputs the contribution analysis results. These results include the analysis results corresponding to each of the three checks.

[0090] For example, if a semantic conflict is found between the root cause summary in the historical reference results and the anomaly of the sub-parsing unit, or if there are omissions in the appendix check results that are not mentioned in the problem description, or if the sub-parsing unit cannot confirm the relevant hypotheses generated by the large language model based on the historical reference results and the appendix check results, then the contribution analysis results corresponding to the sub-parsing unit should clearly mark the potential biases, omissions, or hypotheses to be verified, to ensure that the input information for subsequent comprehensive judgment is comprehensive, true, and has undergone multiple verifications.

[0091] Step S240.6: Based on the contribution analysis results corresponding to the multiple sub-analysis units, obtain the set of attachment analysis results.

[0092] In this embodiment, the contribution analysis results of all sub-analysis units are summarized, deduplicated, and sorted by relevance to obtain the set of appendix analysis results.

[0093] The appendix analysis results set includes the contribution analysis results corresponding to each sub-analysis unit.

[0094] Step S250: Input the historical reference results, attachment inspection results, attachment analysis results set and problem description into the multi-model collaborative judgment device, and output the first analysis conclusion.

[0095] In this embodiment, the multi-model collaborative analysis tool includes three specialized sub-models: a code logic analysis sub-model, an operation and maintenance architecture analysis sub-model, and a diagnostic pattern matching sub-model. These three types of models each have their own functions and complement each other.

[0096] In one example, a preset consistency threshold of 80% is set. When the consistency of conclusions from multiple sub-models is greater than or equal to this threshold, the first analytical conclusion is considered a high-confidence conclusion. When the consistency of conclusions from multiple sub-models is less than this threshold, the rule engine is activated for arbitration, using the analysis results from the appendix data as the core criterion for judgment.

[0097] In one embodiment of this application, step S250 inputs the historical reference results, attachment inspection results, attachment analysis result set and problem description into the multi-model collaborative judgment device and outputs the first analysis conclusion, including: steps S250.1 to S250.2.

[0098] Step S250.1: Combine the historical reference results, attachment inspection results, attachment analysis results set and problem description into a comprehensive prompt word, and input them into at least two dedicated sub-models to obtain the output results corresponding to at least two dedicated sub-models respectively.

[0099] In this embodiment, the input of historical reference results, attachment inspection results, attachment analysis results, and problem description is combined into a comprehensive prompt word, which is then input into each sub-model. Each sub-model can independently output a conclusion. This conclusion includes the predicted root cause, risk level, suggested solution, and confidence score.

[0100] The specialized sub-model can include one of the following: a code logic analysis sub-model, an operations and maintenance architecture analysis sub-model, or a diagnostic pattern matching sub-model. The comprehensive prompt words are standardized input text that has been normalized.

[0101] The code logic model focuses on analyzing code vulnerabilities and interface logic anomalies. The operations and maintenance architecture model focuses on analyzing resource consumption, configuration issues, and link failures. The diagnostic mode model focuses on matching historical common failure patterns. Each sub-model reasons independently and does not interfere with each other, outputting its own unique judgment conclusions.

[0102] Step S250.2: Determine the first analytical conclusion based on the output results of at least two dedicated sub-models.

[0103] In this embodiment, a weighted voting algorithm is used to weight the outputs of each sub-model to obtain the first analysis conclusion. The weights of each sub-model can be dynamically adjusted based on historical analysis accuracy and domain fit.

[0104] The first analytical conclusion includes predicted root causes, risk levels, recommended solutions, and confidence scores.

[0105] Step S260: Write the first analysis conclusion back to the target problem.

[0106] In this embodiment, the initial analysis conclusion is written back to the issue sheet for the target problem and published as a comment. This provides engineers with a clear and actionable reference.

[0107] Based on steps S210-S260 above, fully automated intelligent analysis of the target problem is achieved. By integrating semantic retrieval of the problem description, global anomaly scanning of attachments, and in-depth analysis of key fragments, and combining these three with a multi-model collaborative analyzer, the system can output structured root cause localization and solutions. This method effectively solves the problems of information overload, difficulty in reusing experience, superficial attachment analysis, and reliance on personal experience in traditional manual analysis. Experiments show that the initial analysis time can be reduced from several hours to several minutes, significantly improving the efficiency of problem processing and the consistency and reliability of conclusions.

[0108] In one embodiment of this application, after writing the first analysis conclusion back to the target problem in step S260, the method further includes steps S270 to S300.

[0109] Step S270: Check if there is any new feedback information for the target issue; feedback information includes engineer comments, status changes, and new attachments.

[0110] In this embodiment, the subsequent dynamics of the analyzed problem (i.e., the target problem in step S210) are continuously monitored, and the monitored content is analyzed to determine whether there is any new feedback information. Feedback information may include: deviations in the analysis conclusions explicitly pointed out by the engineer (i.e., engineer comments), the problem being reopened (i.e., status change), and the addition of new critical logs (i.e., new attachments).

[0111] In one example, the presence of new feedback information can be determined by setting conditions and using a lightweight large language model. These conditions can include at least one of the following: engineer comments contain preset keywords; the issue status has been reopened from resolved; new attachments have been added; the status change has not been closed for an extended period, etc. If these conditions are met, it is determined that new feedback information exists for the target issue.

[0112] A lightweight large language model can be a binary classification model based on text embeddings and classifiers, which can be used to determine whether the comments on a target question contain new feedback information.

[0113] Step S280: If new feedback information is detected for the target problem, determine whether the feedback information is valid feedback information based on the feedback information and the first analysis conclusion.

[0114] In this embodiment, valid feedback information can be feedback information that can correct, supplement, or overturn the original analysis conclusion (i.e., the first analysis conclusion in step S250), and is different from meaningless feedback such as "solved" or "thank you". If the new feedback information conflicts with the first analysis conclusion, then the feedback information is valid.

[0115] Step S290: If the feedback information is valid, update the first analysis conclusion based on the valid feedback information to obtain the second analysis conclusion.

[0116] In this embodiment, firstly, the scope of influence of the effective feedback information is assessed. If the effective feedback information significantly conflicts with the first analysis conclusion in step S250 (e.g., the engineer denies the root cause or a new attachment reveals a completely different error), a full re-analysis is initiated. The effective feedback information is treated as a newly added problem description, and steps S210 to S250 are re-executed to regenerate the first analysis conclusion. This regenerated first analysis conclusion is the second analysis conclusion. If the effective feedback information supplements or optimizes the first analysis conclusion in step S250 (e.g., provides additional configuration suggestions), incremental analysis is initiated. That is, the effective feedback information is analyzed, and supplementary optimizations are made based on the first analysis conclusion. This eliminates the need to rerun the entire process, resulting in higher efficiency. Finally, the second analysis conclusion is output.

[0117] Step S300: Add the second analysis conclusion to the target problem.

[0118] Based on steps S270 to S300 above, this technical solution achieves dynamic iteration and continuous optimization of the analysis conclusions. By automatically detecting feedback information such as engineer comments, status changes, and added attachments, and judging their validity, the analysis conclusions can be updated under the trigger of valid feedback, forming a closed-loop mechanism of "analysis-feedback-optimization". This mechanism significantly improves the system's adaptability and analysis accuracy, avoiding the drawbacks of traditional solutions where analysis conclusions are "executed once and cannot be corrected", ensuring that the problem analysis results can be continuously refined as information evolves, and improving the flexibility and reliability of problem handling.

[0119] In one embodiment of this application, the historical case database is constructed through the following steps S310 to S380: Step S310: Obtain the historical issue database corresponding to the target project scope.

[0120] In this embodiment, historical issues within the target project scope are retrieved in batches via the project management platform's API. The target project scope can be a custom-configured filter boundary, which can limit the target project, issue type, time range, version range, etc., but is not specified here.

[0121] For example, the target project is "Backend", the issue type is "Bug", the time range is "last 6 months", and the version range is "V2.0 and above".

[0122] Step S320: According to preset rules, candidate historical questions are selected from the historical question database to obtain a candidate historical question set.

[0123] In this embodiment, the preset rules may include: the status is closed and the solution result is resolved; the title, description, root cause summary, and solution fields are not empty; it contains at least one attachment, or there is a clear solution description in the comments; it is not marked as invalid or duplicate; the last update time is not earlier than a preset time; and the proportion of positive feedback (such as "helpful" or "solved") in the comments exceeds a preset proportion threshold.

[0124] This preset rule is a high-quality knowledge extraction standard used to eliminate invalid, incomplete, and unverified low-quality historical problem cases, and retain only reusable high-quality historical cases.

[0125] The candidate historical issues are stored in a central repository of high-quality, resolved, closed, and verified historical issues.

[0126] Step S330: For each candidate historical problem in the candidate historical problem set, based on the root cause summary and solution of the candidate historical problem, analyze the attached data of the candidate historical problem and extract the related event fragments corresponding to the candidate historical problem.

[0127] In this embodiment, the attachment analysis model is invoked, and combined with the known root causes and solutions of the candidate historical problem, the attachment data of the candidate historical problem is reverse-analyzed. Irrelevant and redundant logs are removed, and core attachment fragments that can directly verify the root cause or key solution steps are extracted from the attachment data as related event fragments. This achieves a one-to-one correspondence between "root cause-solution-evidence".

[0128] Related event fragments can be standardized evidence fragments of candidate historical issues, such as root cause summaries of candidate historical issues, core logs, error codes, and configuration information that can directly corroborate the implementation of solutions.

[0129] Step S340: Based on the metadata of the candidate historical questions and the associated event fragments, determine the knowledge entries corresponding to the candidate historical questions to obtain the knowledge entry set corresponding to the candidate historical question set.

[0130] In this embodiment, for any candidate historical problem, the corresponding knowledge entry is determined based on the candidate historical problem's metadata and related event fragments. One candidate historical problem corresponds to one knowledge entry, thus the set of candidate historical problems corresponds to a set of knowledge entries. Metadata includes problem identifier, operating system version, root cause summary, and solution. Knowledge entries are standardized storage units in the historical case database, possessing a unified structure, complete information, and direct retrieval and reuse capabilities.

[0131] By integrating and unifying fragmented metadata of subsequent historical issues with related event fragments, the problem of data fragmentation is eliminated, and standardized knowledge entries are generated.

[0132] Step S350: Determine the diagnostic mode for the problem class based on multiple knowledge entries belonging to the same type of problem in the knowledge entry set.

[0133] In this embodiment, commonalities are mined from multiple knowledge entries of similar problems in the knowledge entry set to extract general features, root causes, troubleshooting logic, and solutions. This generates diagnostic patterns, checkpoint lists, and feature tags (e.g., "database connection pool exhaustion pattern," "cache breakdown feature") corresponding to this type of problem. The diagnostic patterns will serve as reusable diagnostic rules for rapid matching and reasoning in future problems.

[0134] Diagnostic patterns are general abstract templates for similar problems, used to batch adapt to new faults of the same type and achieve rapid diagnosis. Diagnostic patterns can include: pattern name, general root cause description, typical feature labels, checkpoint list, and solution pattern.

[0135] Step S360: Based on the knowledge entries and metadata of the candidate historical problems, and the diagnostic mode to which the candidate historical problems belong, construct a vector database and a vector library index of the candidate historical problems.

[0136] In this embodiment, for a candidate historical question, the knowledge entries for that candidate historical question and the diagnostic mode to which it belongs are vectorized, associated and bound with the metadata of the candidate historical question, and stored in a vector database. Simultaneously, a vector database index for the candidate historical question is constructed. This vector database index includes a vector retrieval index and a field index.

[0137] By constructing a vector library index of candidate historical questions, the matching speed and accuracy of subsequent online searches can be significantly improved.

[0138] Step S370: Construct a knowledge graph based on the technical entities in the knowledge entry set and the semantic relationships between them.

[0139] In this embodiment, an information extraction model is used to batch identify technical entities in the knowledge entry set and the semantic relationships between any two technical entities. A knowledge graph is constructed using technical entities as nodes and semantic relationships as directed edges to achieve visualization of fault chains and relational reasoning. Technical entities may include microservice names, API interfaces, error types, etc. Semantic relationships between any two technical entities may include causing, depending on, having a fix, or being common to, etc. No further limitations are imposed here.

[0140] In one example, a graph database is used to store technical entity nodes and semantic relationship edges in the knowledge graph, and a graph database index is built.

[0141] Step S380: Construct a historical case database based on the vector database and knowledge graph.

[0142] In this embodiment, the historical case database may be composed of a vector database and a knowledge graph.

[0143] Based on steps S310-S380 above, a structured, semantic, and reusable historical knowledge base was constructed. Through the screening of historical issues, knowledge extraction, diagnostic pattern abstraction, vectorized storage, and knowledge graph construction, discrete historical issues are transformed into efficient and searchable knowledge assets. The refinement of diagnostic patterns and the establishment of the knowledge graph enable not only semantic-level historical experience retrieval but also support for associative reasoning and interpretability analysis. This construction method provides high-quality, highly relevant knowledge support for online analysis processes, significantly improving knowledge reuse efficiency and analytical accuracy. In one embodiment of this application, the method further includes steps S390 to S440.

[0144] Step S390: Obtain the updated historical problem database corresponding to the target project.

[0145] In this embodiment, the project management platform is polled at set time intervals to obtain the updated historical issue database corresponding to the target project.

[0146] Step S400: For each new historical question in the updated historical question database, generate a corresponding new knowledge entry to obtain a set of new knowledge entries.

[0147] In this embodiment, the new historical question can be a newly added question or a question that has changed; no limitation is made here. The newly added knowledge entry set includes new knowledge entries but does not include the knowledge entry set in step S340.

[0148] The new knowledge entry corresponding to the new historical question is generated in the same way as steps S330 and S340 above, which will not be elaborated here.

[0149] Step S410: For the first type of knowledge entries in the newly added knowledge entry set, associate the first type of knowledge entries with the corresponding diagnostic patterns; wherein, the first type of knowledge entries are knowledge entries that can be matched with diagnostic patterns in the historical case database.

[0150] In this embodiment, the newly added knowledge entry set is divided into two categories: a first category and a second category, through semantic matching and feature comparison. The first category consists of knowledge entries that can be matched with diagnostic patterns in the historical case database. The second category consists of knowledge entries that cannot be matched with diagnostic patterns in the historical case database. For each first category knowledge entry, it is associated with its corresponding diagnostic pattern.

[0151] Step S420: For the second type of knowledge entries in the newly added knowledge entry set, determine the corresponding diagnostic pattern based on multiple new knowledge entries belonging to the same type of problem in the second type of knowledge entries; wherein, the second type of knowledge entries are knowledge entries that cannot be matched with a diagnostic pattern in the historical case database.

[0152] In this embodiment, for multiple new knowledge entries belonging to the same type of problem within the second category of knowledge entries, a diagnostic pattern corresponding to that type of problem is generated. The method for determining this diagnostic pattern is essentially the same as step S350 described above, and will not be elaborated upon here.

[0153] Step S430: Determine the vector library index of the new historical problem based on the knowledge entries and metadata of the new historical problem, as well as the diagnostic mode of the new historical problem.

[0154] This step is basically the same as step S360 above, and will not be described again here.

[0155] Step S440: Update the knowledge graph based on the newly added technical entities and newly added semantic relationships in the newly added knowledge entry set to obtain the updated knowledge graph.

[0156] In this embodiment, a batch identification method is used to identify new technical entities and new semantic relationships in the newly added knowledge entry set. Using the new technical entities as nodes and the new semantic relationships as directed edges, the knowledge graph obtained in step S370 is updated to obtain the updated knowledge graph.

[0157] In one example, if a graph database is used to store technical entity nodes and semantic relationship edges in a knowledge graph, then the graph database index in the graph database is updated simultaneously with the knowledge graph.

[0158] Based on steps S390 to S440 above, incremental dynamic updates of the historical knowledge base are achieved. Through automatic knowledge extraction, diagnostic pattern matching, or new pattern mining for newly added historical issues, as well as synchronous updates of vector indexes and knowledge graphs, new knowledge can be continuously absorbed and the knowledge structure optimized without reconstructing the entire database. This mechanism ensures the timeliness and scalability of the knowledge base, enabling the system to evolve with the ability to "learn as it's used and become more accurate with use," effectively supporting the continuous accumulation and reuse loop of organizational knowledge assets.

[0159] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the above method embodiments.

[0160] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0161] This disclosure may be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement any of the methods in the foregoing embodiments of this disclosure.

[0162] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media may include, for example, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), compact disc-read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any combination thereof. The computer-readable storage medium used herein is not to be interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0163] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include one or more of copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to computer-readable storage media in the respective computing / processing device.

[0164] The computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object programs written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as the "C" language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network (e.g., a local area network or a wide area network), or it may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays, or programmable logic arrays, can execute computer-readable program instructions to implement various aspects of the embodiments of this disclosure by utilizing state information from the computer-readable program instructions.

[0165] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus, and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0166] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0167] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0168] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It should be noted that implementation in hardware, implementation in software, and implementation using a combination of software and hardware are all equivalent.

[0169] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of this disclosure is defined by the appended claims.

Claims

1. A data processing method, characterized in that, include: Acquire multi-source data for the newly created target problem; the multi-source data includes problem data and attachment data, and the problem data includes a problem description. Based on the problem description, retrieve historical case databases to obtain historical reference results; Identify abnormal information in the attachment data to obtain the attachment inspection results; Determine the sequence of target parsing units associated with the problem description from the attached data, and determine the set of attached analysis results based on the sequence of target parsing units; The historical reference results, the attachment inspection results, the attachment analysis results set, and the problem description are input into the multi-model collaborative judgment device, and the first analysis conclusion is output. The first analytical conclusion is then written back to the target problem.

2. The method according to claim 1, characterized in that, The step of retrieving historical case databases based on the problem description to obtain historical reference results includes: Convert the problem description into a problem semantic vector; Based on the semantic similarity between the problem semantic vector and each knowledge entry in the historical case database, a first number of resolved historical cases are selected from the historical case database as a candidate historical case set. Reference historical cases are selected from the candidate historical case set as historical reference results.

3. The method according to claim 1, characterized in that, The process of identifying abnormal information in the attachment data and obtaining attachment inspection results includes: If the amount of data in the attachment data is greater than or equal to the data volume threshold, candidate attachment fragments are selected from the attachment data using a preset filtering method. The candidate attachment fragment is divided into multiple parsing units; For any parsing unit, identify whether there is abnormal information in the parsing unit, and obtain the identification result corresponding to the parsing unit; The attachment inspection result is determined based on the identification results corresponding to the multiple parsing units.

4. The method according to claim 1, characterized in that, The step of determining the target parsing unit sequence associated with the problem description from the attached data, and determining the attachment analysis result set based on the target parsing unit sequence, includes: If the amount of data in the attachment data is greater than or equal to the data volume threshold, candidate attachment fragments are selected from the attachment data using a preset filtering method. The candidate attachment fragment is divided into multiple parsing units, and the multiple parsing units are vectorized to obtain multiple parsing unit vectors; Based on the semantic similarity between the semantic vector corresponding to the problem description and the plurality of parsing unit vectors, a second number of target parsing units are selected from the plurality of parsing unit vectors to obtain a target parsing unit sequence. If the total text volume of the target parsing unit sequence is greater than the threshold of the model input text volume, the target parsing unit sequence is divided into multiple sub-parsing units; Input each of the multiple sub-parsing units, the problem description, the historical reference results, and the attachment check results into the large language model, and output the contribution analysis results corresponding to the sub-parsing unit; The set of appendix analysis results is obtained based on the contribution analysis results corresponding to the multiple sub-analysis units.

5. The method according to claim 1, characterized in that, The process involves inputting the historical reference results, the attachment inspection results, the attachment analysis results set, and the problem description into a multi-model collaborative analysis device, and outputting a first analysis conclusion, including: The historical reference results, the attachment inspection results, the attachment analysis results, and the problem description are combined into a comprehensive prompt word, which is then input into at least two dedicated sub-models to obtain the output results corresponding to the at least two dedicated sub-models respectively; the dedicated sub-model includes one of the code logic analysis model, the operation and maintenance architecture analysis model, and the diagnostic pattern matching model. The first analytical conclusion is determined based on the output results of the at least two specialized sub-models.

6. The method according to claim 1, characterized in that, After writing back the first analytical conclusion to the target problem, the method further includes: Check if there is any new feedback information regarding the target issue; the feedback information includes engineer comments, status changes, and newly added attachments. If new feedback information is detected regarding the target issue, based on the feedback information and the first analysis conclusion, it is determined whether the feedback information is valid: If the feedback information is valid, the first analysis conclusion is updated based on the valid feedback information to obtain the second analysis conclusion. Add the second analytical conclusion to the target problem.

7. The method according to claim 1, characterized in that, The historical case database is constructed through the following steps: Obtain the historical issue database corresponding to the target project scope; According to preset rules, candidate historical questions are selected from the historical question database to obtain a candidate historical question set; For each candidate historical problem in the candidate historical problem set, based on the root cause summary and solution of the candidate historical problem, the attached data of the candidate historical problem is analyzed, and the related event fragments corresponding to the candidate historical problem are extracted. Based on the metadata of the candidate historical questions and the associated event fragments, the knowledge entries corresponding to the candidate historical questions are determined, and the knowledge entry set corresponding to the candidate historical question set is obtained; Based on multiple knowledge entries belonging to the same type of problem in the knowledge entry set, determine the diagnostic pattern of the problem type; Based on the knowledge entries and metadata of the candidate historical problems, and the diagnostic modes to which the candidate historical problems belong, construct a vector database and a vector library index for the candidate historical problems; Based on the technical entities in the knowledge entry set and the semantic relationships between them, a knowledge graph is constructed. The historical case database is constructed based on the vector database and the knowledge graph.

8. The method according to claim 7, characterized in that, The method further includes: Obtain the updated historical issue database corresponding to the target project; For each new historical question in the updated historical question database, a corresponding new knowledge entry is generated, resulting in a set of new knowledge entries; For the first type of knowledge entries in the newly added knowledge entry set, the first type of knowledge entries are associated with the corresponding diagnostic patterns; wherein, the first type of knowledge entries are knowledge entries that can be matched with diagnostic patterns in the historical case database; For the second category of knowledge entries in the newly added knowledge entry set, a corresponding diagnostic pattern is determined based on multiple new knowledge entries belonging to the same type of problem in the second category of knowledge entries; wherein, the second category of knowledge entries are knowledge entries that cannot be matched with a diagnostic pattern in the historical case database; Based on the knowledge entries and metadata of the new historical problem, as well as the diagnostic pattern of the new historical problem, determine the vector library index of the new historical problem; The knowledge graph is updated based on the newly added technical entities and semantic relationships in the newly added knowledge entry set, resulting in an updated knowledge graph.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory being used to store computer instructions, and the processor being used to retrieve the computer instructions from the memory to perform the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method according to any one of claims 1-8.

Images