Intelligent software compatibility problem detection method based on pre-training language model

Abstract

The invention discloses an intelligent software compatibility problem detection method based on a pre-training language model, and the method comprises the steps: collecting non-labeled Python stack tracking data and labeled Python stack tracking data, so as to construct a pre-training data set and a fine-tuning data set; analyzing the Traceback data and unifying the format of the Traceback data; processing the Traceback data exceeding the maximum length limit of the model; unsupervised retraining is carried out on the basis of the BERT model by using unlabeled Traceback data, and Traceback semantic features are learned; constructing an intelligent software compatibility problem detection model; dividing a fine tuning data set, selecting positive example data in the training set to construct a fine tuning training set with balanced categories, and performing fine tuning on the classification model by using a small amount of data sets with labels; according to the method, the problem that an existing method cannot automatically detect the compatibility in the operation process of the intelligent software is solved, the limitation of an existing model in the aspect of understanding Python Traceback context semantic features is overcome, the dependency relationship between stack frames and abnormal information can be fully captured, and the accuracy of intelligent software compatibility problem detection is effectively improved.

Description

Technical Field

[0001] The present invention belongs to the field of intelligent software compatibility problem detection in software engineering, and specifically relates to an intelligent software compatibility problem detection method based on a pre-trained language model. Background Art

[0002] With the in-depth development of deep learning technology, intelligent software plays an increasingly important role in human society. Intelligent software consists of multiple complex and interacting components, including the core program (CORE), Python language and its interpreter, third-party library (TPL), low-level library (LLL), development tools (DEV), operating system (OS) and hardware environment. Due to the asynchronous evolution of these components, problems such as version mismatch between components or inconsistency between the called third-party library API version and the actually used third-party library API version frequently occur. The incompatible interaction problem between components is called the compatibility problem of intelligent software. Due to the diversity and complexity of intelligent software components, various compatibility problems arise, such as CORE-TPL, TPL-TPL and TPL-LLL.

[0003] As the complexity and scale of intelligent software increase, compatibility issues between system components become increasingly serious, posing a great threat to software development and maintenance. Intelligent software compatibility issues frequently occur during system operation, which may cause system crashes or functional failures, thereby increasing the complexity and cost of developers and maintenance teams. When a program crashes, the stack traceback data generated by the system records the exception stack information during program operation, which provides a key basis for analyzing and detecting compatibility issues of intelligent software. However, since Traceback is a semi-structured data, traditional tools are difficult to effectively analyze and understand this type of data.

[0004] With the development of pre-trained language models, they have shown great potential in natural language understanding. Many studies have made the model perform better in understanding task-specific data by retraining on specific data. Currently, in open source platforms such as GitHub and Stack Overflow, it takes a lot of time and cost to collect and annotate data. Therefore, only a small amount of labeled data is available. In this context, the pre-training and fine-tuning paradigm has been widely used. This method can make full use of a large amount of unlabeled data and a small amount of labeled data, so that the model can better capture the characteristics of the data.

[0005] Therefore, the present invention proposes an intelligent software compatibility problem detection method based on a pre-trained language model. The method adopts a pre-training and fine-tuning paradigm to fully understand the dependencies between contexts in Traceback data and achieve better automatic detection performance of intelligent software compatibility problems with less labeled data. Summary of the invention

[0006] Purpose of the invention: The present invention proposes a method for detecting intelligent software compatibility issues based on a pre-trained language model, which can effectively improve the accuracy of detecting intelligent software compatibility issues.

[0007] Technical solution: The intelligent software compatibility problem detection method based on a pre-trained language model described in the present invention specifically includes the following steps:

[0008] (1) Collect unlabeled and labeled Python stack traceback data from GitHub and Stack Overflow, remove irregular data, and use it to build pre-training datasets and fine-tuning datasets;

[0009] (2) The original traceback data is parsed, the traceback format is unified, and the file path, line number, function name, error code, and exception information in each stack frame are extracted to reduce irrelevant data noise;

[0010] (3) Count the length of the stack frame and exception information respectively, and design a custom algorithm to truncate the data exceeding the maximum length of the model to retain the core features of the stack frame and exception information;

[0011] (4) Based on the BERT pre-training model, the Traceback data processed in step (3) is used to perform masked language model MLM pre-training to obtain a Traceback context semantic representation pre-training model;

[0012] (5) Combining the pre-trained model obtained in step (4) with the multi-head attention mechanism layer, the Dropout layer, and the fully connected layer to build an intelligent software compatibility problem classification model;

[0013] (6) Select samples with positive labels from the labeled Traceback data training set, construct a class-balanced data set through data augmentation, and then train the intelligent software compatibility problem classification model constructed in step (5) until a preset number of training cycles is reached.

[0014] Furthermore, the implementation process of step (1) is as follows:

[0015] Collect traceback data from GitHub and Stack Overflow through custom rules, use regular expressions to clean up redundant symbols in the data, and remove incomplete or non-standard traceback records;

[0016] By analyzing the dataset, we identify two mainstream traceback formats, and construct a fine-tuning dataset by manually extracting traceback data in these two mainstream formats from annotated StackOverflow classified posts.

[0017] Furthermore, the implementation process of step (2) is as follows:

[0018] According to the main features of the Traceback data, the file path, line number, method name and code in the stack frame are retained, and the two mainstream Traceback data formats are processed into a unified mode.

[0019] The file path is considered as variable information. Even in the same execution environment, the special symbol "<*>" is used to represent the variable part of the file path because the paths of different machines are different. Only the file name is retained. For paths involving third-party libraries, the keyword and the part following it are retained. The separators "\" or "\\" in the file path are replaced with " / " to prevent the word breaker from understanding them as escape characters. When the file path, line number, function name, or code is missing in the stack frame, in order to maintain context consistency, the placeholders [FILE], [NUM], [FUNC], and [CODE] are used to replace the missing information.

[0020] Furthermore, the implementation process of step (3) is as follows:

[0021] Use [SEP] to separate different stack frames and exception information, add the special symbol "<*>" added in step (2) and the placeholders [FILE], [NUM], [FUNC], and [CODE] to the vocabulary, and perform word segmentation on the input sequence;

[0022] For tracebacks that exceed the maximum length limit of the model, a custom truncation algorithm is used to retain important features: First, the lengths of the stack frames and exception information of all tracebacks are counted, and the maximum lengths of the stack frames and exception information are determined based on the number of tracebacks covered by the length and the overall maximum length. The maximum length of the exception information is 50; the maximum length of the stack frame is 460. The specific method is as follows:

[0023] If the entire traceback length exceeds the maximum length limit of BERT, the exception information in the traceback is truncated first; if the traceback length still exceeds the model limit after truncating the exception information, the stack frames are truncated one by one from the front until the entire sequence meets the allowed length.

[0024] Furthermore, the implementation process of step (4) is as follows:

[0025] After processing in step (3), we get the input sequence X = {x1, x2, …, x t ,…,x T}, where x t Represents a token; pre-train the masked language task based on the pre-trained model, randomly replace the tokens in the input sequence X with a preset probability, and replace them with X mask Indicates the replaced tokens, and this damaged version is recorded as The training goal is to reconstruct the mask sequence The statement is as follows:

[0026]

[0027] Among them, θ represents the learnable parameters of the model, including all weights and biases; H θ represents an encoder based on the Transformer layer, mapping the sequence X to a series of hidden vectors; e(x) is the word embedding of the token x from the Transformer embedding layer, T is the transposition operation, ∑ x ′ is the sum of all tokens in the vocabulary; the preset probability is 0.15.

[0028] Furthermore, the implementation process of step (5) is as follows:

[0029] Use the pre-trained model obtained in step (4) as the encoder of the traceback data and embed it to obtain Next, the dependencies between words are further captured through a multi-head attention mechanism layer; the multi-head attention mechanism consists of multiple self-attention layers, each of which extracts features by calculating the weight matrix of query, key, and value, denoted as: Then, the output of the attention mechanism is added to the original encoder output using a residual connection, and the representation H after the residual connection is attention (X) is input to the linear classification layer and the softmax function is used to output the predicted probability of each different category.

[0030] Furthermore, the implementation process of step (6) is as follows:

[0031] Divide the fine-tuning dataset into a training set, a validation set, and a test set. Select data labeled as positive examples from the training set, randomly replace the row numbers of this part of the data, generate a class-balanced training dataset with the same number of positive examples and negative examples, and keep the ratio of positive examples to negative examples in the test set and validation set unchanged.

[0032] Input the balanced training set, validation set, and test set into the intelligent software compatibility problem classification model constructed in step (5); adjust the model parameters and training cycle by the value of the loss function until the training loss and validation loss tend to be stable; in each training cycle, use the adjusted parameter settings to iteratively train the weight matrix w and the bias term b; use the softmax function to convert the vector H(x i ) is mapped to each category to obtain the tensor z j The corresponding probability score is as follows:

[0033] y j =softmax(z j )=softmax(w j ·x+b j )

[0034] The loss function for classification model training is expressed as:

[0035]

[0036] Among them, N represents the number of training samples in each batch, y j represents the true label value of the jth sample. The non-compatible sample is 0, and the compatible sample is 1. j represents the predicted probability of the jth class.

[0037] Beneficial effects: Compared with the prior art, the beneficial effects of the present invention are as follows: the present invention combines pre-training and fine-tuning paradigms to realize intelligent software compatibility problem detection; uses Traceback data as a source for obtaining compatibility problem information, and pre-trains the model through an unsupervised learning method to fully learn the connection between different stack frames and exception information in the Traceback data; uses the pre-trained model as an encoder in the fine-tuning stage, and uses a multi-head attention mechanism to further strengthen the connection between Traceback context features, and trains the classification model by enhancing the fine-tuning training set; the present invention solves the problem that the existing methods cannot automatically detect compatibility problems that occur during the operation of intelligent software. The proposed Traceback pre-training model overcomes the limitations of the existing models in understanding the semantic features of the Traceback context, can fully capture the dependency between stack frames and exception information, and effectively improves the accuracy of intelligent software compatibility problem detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 is a flow chart of the present invention;

[0039] Figure 2 The overall framework diagram of the compatibility problem classification model constructed for the present invention;

[0040] Figure 3 This is the Traceback analysis diagram proposed by the present invention;

[0041] Figure 4 There are two mainstream traceback formats. DETAILED DESCRIPTION

[0042] The present invention is further described in detail below in conjunction with the accompanying drawings.

[0043] like Figure 1 , Figure 2 As shown, the present invention proposes an intelligent software compatibility problem detection method based on a pre-trained language model, which pre-trains a large amount of Python stack trace (Traceback) data through unsupervised learning to learn the dependency information between contexts in the Traceback data; uses the pre-trained model as an encoder for the Traceback data to build an intelligent software compatibility problem classification model, and uses a multi-head self-attention mechanism to strengthen the dependency relationship between words of different distances; and uses the enhanced labeled data to train the classification model to realize intelligent software compatibility problem detection. Specifically, it includes the following steps:

[0044] Step 1: Collect unlabeled traceback data and labeled traceback data to build pre-training datasets and fine-tuning datasets.

[0045] Define filtering rules to select only data related to the Python language and containing the keyword "Traceback" in the content. In order to collect unlabeled data, first use the GitHub REST API to filter out relevant Traceback data from the GitHub platform according to these rules. Since GitHub issues usually include titles, content bodies, and user comments, by default, the GitHub API searches for keywords in these three parts. In order to initially ensure the integrity of the data, exclude records where keywords only appear in the issue title, and then use regular expressions to extract Traceback data from the content body and comments. Then, remove redundant parts such as special symbols, blank lines, redundant information, and incomplete data in the data.

[0046] Similarly, we filter out posts with the Python tag from the Stack Overflow dump data, further filter out posts with the “Traceback” keyword in their content, and extract untagged Traceback data in the same way as the GitHub data.

[0047] After analyzing the collected unlabeled data samples, we found that there are two traceback formats that account for more than 85%, such as Figure 4 As shown. These two traceback formats come from different IDEs. Figure 4 Format 1 shows the most common traceback format produced in most Python environments, while the other format typically appears in interactive runtime environments such as Jupyter Notebook, as shown in Figure 4 Format 2. Other traceback formats are less common, so they are excluded. To ensure the quality and consistency of the dataset, only traceback data in these two formats are retained.

[0048] In order to obtain labeled data, we used existing annotated Stack Overflow posts. Since the number of labeled data sets is small, we manually extracted the required traceback data in two main formats from these posts using the same rules to ensure the effectiveness and accuracy of the fine-tuned data set.

[0049] Step 2: Parse the traceback data and process the data into a unified format.

[0050] In order to analyze and process the common features of Traceback data, the two formats of Traceback obtained in step 1 are processed into a unified form. Figure 3 As shown, given a Traceback data, denoted as ST = {f1, f2, ..., f n-1 ,f n}, where f i (i∈1,...,n-1) represents the stack frame, f n Indicates exception information. Each traceback data consists of one or more stack frames and an exception message, and the main features of the stack frame include file path, line number, function name and code. In order to extract these core features, regular expressions are used to remove irrelevant information and generate traceback data in a unified format.

[0051] Among them, the file path is considered as variable information. Even in the same execution environment, since the paths of different machines are different, "<*>" is uniformly used to represent the variable part in the file path, and only the file name is retained. For paths involving third-party libraries, the keywords "site-packages" or "dist-packages" are usually included. These keywords and the parts following them are retained because they are very important when detecting compatibility issues. In addition, "\" and "\\" in the file path may be interpreted as special symbols such as "\t" or "\n", so they are uniformly replaced with " / ". When the file path, line number, function name, or code is missing in the stack frame, in order to maintain context consistency, placeholders [FILE], [NUM], [FUNC], and [CODE] are used to replace the missing information. This not only retains key features, but also avoids the interference of irrelevant fields on model training and reduces the risk of overfitting.

[0052] Step 3: Use large-scale unlabeled traceback data to perform unsupervised retraining on the BERT model to learn traceback semantic features and obtain the traceback encoder, i.e., the pre-trained model.

[0053] First, the traceback data needs to be preprocessed and the preprocessed text is input into the BERT model for pre-training, which mainly includes the following steps:

[0054] Considering that the BERT model uses [SEP] to distinguish different sentences, in order to ensure intra-sentence and cross-sentence features, [SEP] is used to separate different stack frames and exception information. Then the special symbols and placeholders used in step 2 are added to the vocabulary, and the input sequence is segmented.

[0055] Then it is necessary to determine whether the Traceback sequence after word segmentation exceeds the maximum length limit of the BERT model. Directly truncating the part that exceeds the maximum length may cause the loss of exception information or incomplete stack frames. Therefore, in order to retain the complete traceback information to the maximum extent, the length distribution of exception information and stack frames in unlabeled and labeled datasets was first evaluated. According to the statistics of the cumulative length of Traceback data, the maximum length limits of exception information and stack frames are set to 50 and 460, respectively. This configuration covers approximately 86% of the Traceback data, ensuring the integrity of most of the data. Subsequently, the Traceback data that exceeds the maximum length limit is truncated in the following two steps to retain key information as much as possible.

[0056] Step 1: If the entire Traceback length exceeds the maximum length limit of BERT, prioritize truncating the abnormal information in the Traceback. This part of information may contain noise that has not been completely cleared. Truncating this part of information helps the model focus more on understanding the direct factors that lead to errors.

[0057] Step 2: If the Traceback length still exceeds the model limit after truncating the exception information, truncate the stack frames one by one until the entire sequence meets the allowed length. Choose to truncate from the front, giving priority to keeping the most recent stack frames, because they are more likely to be directly related to the error.

[0058] Through the above truncation steps, it is ensured that the retained content reflects the original error scenario as completely as possible, thereby helping the model to understand and analyze the cause of the error more accurately.

[0059] Step 4: After processing in step 3, we get the input sequence, X = {x1, x2, …, x t ,…,x T}, where x t Represents a token. The input sequence is input into the model and the language model is trained through self-supervised learning method.

[0060] Following the pre-training strategy of BERT, the Masked Language Task (MLM) is used as its training target. By predicting randomly masked tokens in sentences, the intra-frame relationship and contextual relationship between stack frames are learned, so that the model can fully capture the rich language features and complex contextual relationships in the backtracking sequence, thereby improving the generalization ability of the model. Specifically, the tokens in the input sequence X are randomly replaced with X using a set probability (p = 0.15). mask Indicates the replaced tokens, and this damaged version is recorded as The training goal is to reconstruct the mask sequence It can be expressed as follows:

[0061]

[0062] Among them, θ represents the learnable parameters of the model, usually including all weights and biases; H θ represents an encoder based on the Transformer layer, which can map the sequence X to a series of hidden vectors; e(x) is the word embedding of the token x from the Transformer embedding layer, T is the transposition operation, ∑ x′ is the sum of all tokens in the vocabulary.

[0063] Step 5: Use the pre-trained model obtained in step 4 to build a compatibility problem classification model, including the Traceback encoder, multi-head attention mechanism layer, Dropout layer, and fully connected layer.

[0064] Use the pre-trained model obtained in step 4 as the encoder of the traceback data and embed it to obtain Next, the multi-head attention mechanism is used to further capture the dependencies between words. The multi-head attention mechanism consists of multiple self-attention layers, each of which extracts features by calculating the weight matrix of query, key, and value, denoted as

[0065] In this step, the output of the attention mechanism is added to the original encoder output using a residual connection, maintaining the propagation of gradients and enhancing the richness of feature representation. attention (X) is input into the linear classification layer, each traceback data is classified through the softmax function, and the predicted probability of different categories is output.

[0066] Step 6: Divide the fine-tuning dataset, select the positive data in the training set to construct a class-balanced fine-tuning training set, and use a small amount of labeled dataset to fine-tune the classification model.

[0067] First, the fine-tuning dataset is divided into training set, validation set and test set. Data labeled as positive examples (i.e., traceback data marked as having compatibility issues) are selected from the training set, and the row numbers of this part of the data are randomly replaced to generate a category-balanced training dataset with the same number of positive and negative examples. The ratio of positive and negative examples in the test set and validation set remains unchanged.

[0068] Next, the balanced training set, validation set, and test set are input into the classification model constructed in step 5. The model parameters and training cycle are adjusted by the value of the loss function until the training loss and validation loss are stable. In each training cycle, the weight matrix w and the bias term b are iteratively trained using the adjusted parameter settings. The vector H(x i ) is mapped to each category to obtain the tensor z j The corresponding probability score is as follows:

[0069] y j =softmax(z j )=softmax(w j ·x+b j )

[0070] The loss function for classification model training is expressed as:

[0071]

[0072] Among them, N represents the number of training samples in each batch, y j represents the true label value of the jth sample, the non-compatible sample is 0, and the compatible sample is 1; q j represents the predicted probability of the jth class.

[0073] The above content has described in detail the intelligent software compatibility problem detection method based on the pre-trained language model of the present invention, but it is obvious that the specific implementation form of the present invention is not limited thereto. For those skilled in the art, various obvious changes made to it without departing from the spirit of the present invention and the scope of the claims are within the protection scope of the present invention.

Claims

1. An intelligent software compatibility problem detection method based on a pre-trained language model, characterized in that: The following steps are involved: (1) Collect unlabeled and labeled Python stack traceback data from GitHub and Stack Overflow, remove irregular data, and use it to build pre-training datasets and fine-tuning datasets; (2) The original traceback data is parsed, the traceback format is unified, and the file path, line number, function name, error code, and exception information in each stack frame are extracted to reduce irrelevant data noise; (3) Count the length of the stack frame and exception information respectively, and design a custom algorithm to truncate the data exceeding the maximum length of the model to retain the core features of the stack frame and exception information; (4) Based on the BERT pre-training model, the Traceback data processed in step (3) is used to perform masked language model MLM pre-training to obtain a Traceback context semantic representation pre-training model; (5) Combining the pre-trained model obtained in step (4) with the multi-head attention mechanism layer, the Dropout layer, and the fully connected layer to build an intelligent software compatibility problem classification model; (6) Select samples with positive labels from the labeled Traceback data training set, construct a class-balanced data set through data augmentation, and then train the intelligent software compatibility problem classification model constructed in step (5) until a preset number of training cycles is reached.

2. According to claim 1, a method for detecting intelligent software compatibility issues based on a pre-trained language model is characterized in that: The implementation process of step (1) is as follows: Collect traceback data from GitHub and Stack Overflow through custom rules, use regular expressions to clean up redundant symbols in the data, and remove incomplete or non-standard traceback records; By analyzing the dataset, we identify two mainstream traceback formats, and construct a fine-tuning dataset by manually extracting traceback data in these two mainstream formats from annotated Stack Overflow classified posts.

3. According to claim 1, the intelligent software compatibility problem detection method based on pre-trained language model is characterized in that: The implementation process of step (2) is as follows: According to the main features of the Traceback data, the file path, line number, method name and code in the stack frame are retained, and the two mainstream Traceback data formats are processed into a unified mode. The file path is considered as variable information. Even in the same execution environment, the special symbol "<*>" is used to represent the variable part of the file path because the paths of different machines are different. Only the file name is retained. For paths involving third-party libraries, the keyword and the part following it are retained. The separators "\" or "\\" in the file path are replaced with " / " to prevent the word breaker from understanding them as escape characters. When the file path, line number, function name, or code is missing in the stack frame, in order to maintain context consistency, the placeholders [FILE], [NUM], [FUNC], and [CODE] are used to replace the missing information.

4. According to claim 1, the intelligent software compatibility problem detection method based on pre-trained language model is characterized in that: The implementation process of step (3) is as follows: Use [SEP] to separate different stack frames and exception information, add the special symbol "<*>" added in step (2) and the placeholders [FILE], [NUM], [FUNC], and [CODE] to the vocabulary, and perform word segmentation on the input sequence; For tracebacks that exceed the maximum length limit of the model, a custom truncation algorithm is used to retain important features: First, the lengths of the stack frames and exception information of all tracebacks are counted, and the maximum lengths of the stack frames and exception information are determined based on the number of tracebacks covered by the length and the overall maximum length. The specific method is as follows: If the entire traceback length exceeds the maximum length limit of BERT, the exception information in the traceback is truncated first; if the traceback length still exceeds the model limit after truncating the exception information, the stack frames are truncated one by one from the front until the entire sequence meets the allowed length.

5. The method for detecting intelligent software compatibility issues based on a pre-trained language model according to claim 1, characterized in that: The implementation process of step (4) is as follows: After processing in step (3), we get the input sequence X = {x1, x2, …, x t ,…,x T }, where x t Represents a token; pre-train the masked language task based on the pre-trained model, randomly replace the tokens in the input sequence X with a preset probability, and replace them with X mask Indicates the replaced tokens, and this damaged version is recorded as The training goal is to reconstruct the mask sequence The statement is as follows: Among them, θ represents the learnable parameters of the model, including all weights and biases; H θ represents an encoder based on the Transformer layer, mapping the sequence X to a series of hidden vectors; e(x) is the word embedding of the token x from the Transformer embedding layer, T is the transposition operation, ∑ x′ is the sum of all tokens in the vocabulary.

6. The method for detecting intelligent software compatibility issues based on a pre-trained language model according to claim 1, characterized in that: The implementation process of step (5) is as follows: Use the pre-trained model obtained in step (4) as the encoder of the traceback data and embed it to obtain H θ* (X); Then, the dependencies between words are further captured through the multi-head attention mechanism layer; the multi-head attention mechanism consists of multiple self-attention layers, each of which extracts features by calculating the weight matrix of query, key and value, denoted as: H attention (X) = H θ* (X)+H attention (X); Then use the residual connection to add the output of the attention mechanism to the original encoder output, and the residual connection representation H attention (X) is input to the linear classification layer and the softmax function is used to output the predicted probability of each different category.

7. The method for detecting intelligent software compatibility issues based on a pre-trained language model according to claim 1, characterized in that: The implementation process of step (6) is as follows: Divide the fine-tuning dataset into a training set, a validation set, and a test set. Select data labeled as positive examples from the training set, randomly replace the row numbers of this part of the data, generate a class-balanced training dataset with the same number of positive examples and negative examples, and keep the ratio of positive examples to negative examples in the test set and validation set unchanged. Input the balanced training set, validation set, and test set into the intelligent software compatibility problem classification model constructed in step (5); adjust the model parameters and training cycle by the value of the loss function until the training loss and validation loss tend to be stable; in each training cycle, use the adjusted parameter settings to iteratively train the weight matrix w and the bias term b; use the softmax function to convert the vector H(x i ) is mapped to each category to obtain the tensor z j The corresponding probability score is as follows: y j =softmax(z j )=softmax(w j ·x+b j ) The loss function for classification model training is expressed as: Among them, N represents the number of training samples in each batch, y i represents the true label value of the jth sample. The non-compatible sample is 0, and the compatible sample is 1. j represents the predicted probability of the jth class.

8. The method for detecting intelligent software compatibility issues based on a pre-trained language model according to claim 4, characterized in that: The maximum length of the exception information is 50.

9. The method for detecting intelligent software compatibility issues based on a pre-trained language model according to claim 4, characterized in that: The maximum length of the stack frame is 460.

10. The method for detecting intelligent software compatibility issues based on a pre-trained language model according to claim 5, characterized in that: The preset probability is 0.15.

Images