Business exception processing method and computing device

Abstract

The invention discloses a business exception processing method and computing equipment. The business exception processing method comprises the following steps: acquiring a first embedded representation of business exception, the first embedded representation being generated based on description information of the business exception; calculating the similarity between the first embedded representation and each second embedded representation in at least part of second embedded representations in a vector database, wherein the second embedded representations are embedded representations of at least part of texts of the abnormal case; selecting a first number of abnormal cases with high similarity ranking; judging whether a target abnormal case matched with the business exception exists in the first number of abnormal cases or not by utilizing a first large language model; and processing the business exception by using a first processing scheme of the target exception case under the condition that the target exception case exists.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of artificial intelligence, and in particular relate to a business anomaly handling method and computing device. Background Technology

[0002] During business operations, when a service is blocked due to an anomaly, it needs to be handled to restore service. Traditional anomaly handling processes rely on manual intervention, which has the following significant problems: 1) High repetition: Developers need to frequently query error messages and repeatedly perform similar operations. 2) Low efficiency: For common issues such as non-compliant image / video formats and internal service anomalies, the same operations need to be performed repeatedly. 3) Decision delay: Manual analysis is time-consuming, leading to a longer business recovery cycle and impacting user experience. 4) Insufficient knowledge accumulation: Historical experience has not been effectively transformed into reusable decision-making basis.

[0003] Therefore, a new business exception handling solution is needed to address the shortcomings of manual exception handling. Summary of the Invention

[0004] The first aspect of this specification provides a method for handling business exceptions, including:

[0005] Obtain a first embedded representation of the business exception, which is generated based on the description information of the business exception;

[0006] Calculate the similarity between the first embedding representation and each of the second embedding representations in at least a portion of the second embedding representations in the vector database, wherein the second embedding representation is an embedding representation of at least a portion of the text of the anomalous case;

[0007] Select the top number of abnormal cases based on similarity ranking;

[0008] The first language model is used to determine whether there is a target abnormal case that matches the business abnormality among the first number of abnormal cases;

[0009] In the event of the aforementioned target exception case, the first handling scheme for the target exception case shall be used to handle the business exception.

[0010] A second aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in the first aspect.

[0011] According to the method provided in the embodiments of this specification, by applying RAG technology to business anomaly handling, the pain points of conventional anomaly investigation processes can be solved, enabling business anomaly handling to shift from experience-driven to data-driven, and significantly improving investigation efficiency. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of a business exception handling method in one embodiment of this specification;

[0014] Figure 2 This is a flowchart of a business exception handling method in one embodiment of this specification;

[0015] Figure 3 This is an overall flowchart of business exception handling in one embodiment of this specification;

[0016] Figure 4 This is a data processing flowchart of the RAG write link in one embodiment of this specification;

[0017] Figure 5 This is an interactive timing diagram of the RAG read link in one embodiment of this specification. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0019] The services described in the embodiments of this specification may include various services provided to users. For example, services may include, but are not limited to, question-and-answer services provided to users (such as internal personnel of an enterprise) using a Large Language Model (LLM). A business anomaly refers to an abnormal state in which, during business operations, due to technical failures, user non-compliance, or other reasons, the user-facing business process deviates from its expected goals, cannot proceed normally, or produces unexpected results. When a business anomaly occurs, it is necessary to investigate the cause of the anomaly to ensure the normal operation of the business.

[0020] There are two common solutions for handling business anomalies: rule engine solution and manual investigation solution.

[0021] Rule engine solutions handle exceptions based on predefined rule bases (such as if-else conditional statements). Rules include statements like "return a 400 error if the error log shows an image format incompatibility" or "return a 400 error if the error log shows an FFMpeg decoding failure." The main drawbacks of traditional rule engine solutions include: 1. High rule maintenance costs: new rules are needed for each new exception type, leading to a linear increase in the number of rules and an exponential increase in system complexity; 2. Limited coverage: unable to handle unforeseen exception combinations, relying only on simple string matching for coverage; 3. Lack of self-learning capabilities: unable to automatically optimize rules from historical cases, requiring manual updates for each new exception; 4. High false positive rate: rules are overly generalized, potentially leading to incorrect exception handling.

[0022] The manual troubleshooting approach involves developers manually checking logs, analyzing the causes of errors, and deciding whether to block or fix them. The main drawbacks include: 1. Low efficiency: the average processing time is 60 minutes per error, and when there are many similar anomalies, it consumes a significant amount of developer time; 2. Dispersed knowledge: experience is scattered among individuals, and new employees need 1-2 months to master it; 3. Inability to quantify improvements: lack of data support makes continuous process optimization difficult.

[0023] In view of this, a new business exception handling solution is needed to address the shortcomings of conventional business exception handling solutions.

[0024] Figure 1 This is a schematic diagram of a business exception handling method in one embodiment of this specification.

[0025] See Figure 1 This specification describes an automated anomaly detection process based on Retrieval-Augmented Generation (RAG). The entire process is divided into two parts: RAG writing (offline knowledge base construction) and RAG reading (real-time anomaly handling), which realizes intelligent and automated business anomaly handling.

[0026] The RAG write chain can be executed offline periodically to build and maintain the knowledge base, ensuring that the latest historical data can be accessed during real-time processing. For example, historical cases marked as successful and their solutions can be periodically stored in the knowledge base. Thus, historical troubleshooting experience (such as historical cases and their solutions) can be structured and stored in the knowledge base. Therefore, the knowledge base capacity can be increased with each successful handling of a new anomaly. The knowledge base can support the storage and retrieval of tens of thousands of historical cases.

[0027] The RAG read chain is triggered in real time. When a new business exception occurs, it first retrieves the Top-K (e.g., K=3) historical cases most similar to the business exception from the knowledge base. Next, it calls a large model to analyze whether any historical cases matching the business exception exist among the retrieved cases. If a matching historical case exists, the handling scheme of the matching historical case is applied to process the business exception. Based on the continuously updated nature of the knowledge base, the RAG read chain is scalable, supporting the automatic handling of anomaly types up to an unlimited number of types.

[0028] By applying RAG technology to business anomaly handling, the pain points of conventional anomaly investigation processes can be resolved, enabling business anomaly handling to shift from experience-driven to data-driven, and significantly improving investigation efficiency.

[0029] Compared with rule engine solutions, the business exception handling solution provided in the embodiments of this specification can automatically accumulate historical cases without pre-defining all rules; and the knowledge base can be automatically updated without manual rule maintenance; new exceptions can be automatically fed back to the knowledge base to form a closed loop; and the matching based on historical cases can reduce misjudgments.

[0030] Compared to manual troubleshooting, the business anomaly handling solution provided in this specification is based on objective decision-making using a knowledge base, reducing the impact of human factors. Through RGA retrieval and LLM semantic alignment, anomaly matching and judgment can be completed within seconds, reducing troubleshooting time from minutes to seconds compared to manual troubleshooting. This significantly reduces the cost of manual intervention, frees up developer time, and shortens business response time. By reusing historical solutions, redundant troubleshooting can be avoided, enabling real-time automatic decision-making, accelerating business recovery, effectively reducing developer maintenance costs, and minimizing business interruptions caused by anomalies. The reduction of troubleshooting time to seconds stems from: 1) the vector database supports millisecond-level Top-K retrieval; 2) LLM inference can be completed within 1 second with GPU acceleration; and 3) the entire process can be executed automatically without manual login and log querying.

[0031] The details of the technical solutions provided in this specification are described below with reference to specific embodiments.

[0032] Figure 2 This is a flowchart of a business exception handling method in one embodiment of this specification.

[0033] See Figure 2 In step S210, the first embedded representation of the business exception is obtained.

[0034] Business anomalies refer to new, pending exceptions that are currently occurring. For business anomalies, an embedding model can be used to convert the description of the anomaly into a corresponding vector representation, thus obtaining the first embedded representation. The description of business anomalies is usually recorded in logs. Therefore, log information related to business anomalies can be obtained from the logs, and an embedding model can be used to generate a vector representation of the log information, resulting in the first embedded representation. The obtained log information may include, but is not limited to, the original request (such as the user-inputted original query), error type, system status (e.g., CPU utilization, GPU utilization, memory usage, disk I / O utilization, network bandwidth usage, and other resource usage), and timestamps. Embedding modes can be, but are not limited to, bge-m3 and qwen3-embedding.

[0035] A complete business process typically involves multiple business steps, and an anomaly may occur in one of these steps. However, identifying the business step that caused the anomaly is difficult, costly, and prone to inaccurate identification. Therefore, this specification proposes, in its embodiments, that for a newly occurring business anomaly, log information associated with the trace ID (i.e., related logs) can be obtained based on the business anomaly's trace identifier (traceID), and a first embedded representation of this log information can be generated.

[0036] The traceID of a business exception is the traceID associated with that exception. When an exception is triggered, an alert containing the traceID can be generated, allowing the extraction of related logs based on the traceID. Extracting related logs based on the traceID involves searching the log system using the traceID as the keyword to retrieve log information generated at every stage of the business chain related to the exception. The related logs found based on the traceID record log information from the entire business chain, providing richer contextual semantics about the exception. For example, suppose service A fails to call service B; the error log is in service B, but the root cause is in service A. Therefore, if only the logs from a single service B in the call chain are retrieved, information for error attribution will be lost. Compared to using only fragments of error logs, the full-link logs aggregated based on the traceID can reconstruct the complete context of the exception. The embedded representation generated based on this complete context (i.e., the first embedded representation) can capture the deep semantics of the exception, significantly improving the accuracy of semantic matching with historical cases. Therefore, using associated logs to retrieve and match historical cases can improve the accuracy of retrieval and matching, and avoid the ambiguity of keyword-based retrieval and matching of historical cases.

[0037] In step S220, the similarity between the first embedding representation and each of the second embedding representations in at least a portion of the second embedding representations in the vector database is calculated.

[0038] The vectors stored in the vector database can be called second embedding representations. A second embedding representation is an embedding representation of at least a portion of the text of an exception case. Each exception case corresponding to a second embedding representation has a corresponding first processing solution. The vector database can also be called a knowledge base. For details on constructing the vector database, please refer to the relevant description below. The embedding model used to generate the first embedding representation and the embedding pattern used to generate the second embedding representation can be the same model. Exception cases are historical cases of business exceptions that occurred before they were successfully handled.

[0039] In some embodiments, the at least partial second embedding representation may refer to all second embedding representations in the vector database. That is, the similarity between the first embedding representation and each of the second embedding representations in the vector database can be calculated. The similarity can be calculated using, but is not limited to, cosine similarity.

[0040] In some embodiments, the at least partial second embedding representation can be a second embedding representation obtained by filtering all second embedding representations in the vector database based on preset filtering conditions. For example, if the preset filtering conditions include time filtering conditions, second embedding representations located within a specified time period (e.g., the last 3 days) can be selected from the vector database based on the time information of the second embedding representations to obtain the at least partial second embedding representations. The time information can be stored as one of the metadata items of the second embedding representation, associated with the second embedding representation. The time information can characterize the occurrence time of the abnormal case corresponding to the second embedding representation, or characterize the update time when the second embedding representation was stored in the vector database. For example, if the preset filtering conditions include error type filtering conditions, second embedding representations with error types consistent with the error types of the first embedding representation can be selected from the vector database based on the error types of the first embedding representation to obtain the at least partial second embedding representations. The error type can be stored as one of the metadata items of the second embedding representation, associated with the second embedding representation. By filtering second embedding representations that meet the preset filtering conditions to participate in similarity calculation, the search scope can be narrowed, and the computational load reduced.

[0041] In step S230, select the first number of abnormal cases with the highest similarity ranking.

[0042] After calculating the similarity between the first and second embedding representations, the abnormal cases associated with the second embedding representation can be ranked in descending order of similarity. The top-ranked first number of abnormal cases are selected as the abnormal cases similar to the current business anomaly recalled from the vector database. The specific value of the first number can be set according to the actual situation. For example, the first number can be 3.

[0043] In step S240, the first large language model is used to determine whether there is a target abnormal case that matches the business abnormality among the first number of abnormal cases.

[0044] The first batch of anomaly cases selected based on similarity can be considered as historical cases related to the current business anomaly. These first batch of anomaly cases are only semantically similar to the business anomaly, but it's impossible to determine whether the causal logic of the anomalies is consistent (for example, two anomalies both involve "insufficient memory," but one is due to an overly large model, and the other to excessive concurrency, resulting in drastically different handling solutions). Therefore, it's necessary to introduce a large language model to perform semantic alignment analysis on the recalled anomaly cases, determining whether their root causes and handling logic are applicable to the current anomaly, and avoiding the misuse of mismatched anomaly cases.

[0045] Therefore, after selecting the first number of exception cases, the first large language model can be used to determine whether there is a target exception case among the first number of exception cases that matches the business exception. That is, to determine whether there is a target exception case among the first number of exception cases that is applicable to the current business exception (i.e., the cause of the exception is the same as the current business exception, and the processing logic is applicable to the current business exception).

[0046] In some exemplary implementations, a prompt can be constructed based on the exception description of the business exception, the exception descriptions of a first number of exception cases, and their handling solutions. The constructed prompt is then input into a first large language model, which determines whether there is a target exception case among the first number of exception cases that matches the business exception. The exception description of the business exception may, for example, include the associated logs found based on the traceID of the business exception, as mentioned above.

[0047] For example, a first input prompt can be generated based on the description information of the business exception, the description information of each exception case in a first number of exception cases, and the handling solution. This first input prompt is then input into a first large language model to obtain the judgment result output by the first large language model. Specifically, the first input prompt instructs the first large language model to determine whether there exists a target exception case among the first number of exception cases whose cause is consistent with the business exception. For example, the structure of the first input prompt can be designed as: "Explanation of the current business exception; First number of exception cases: [Exception case 1: <Exception description + handling solution>, Exception case 2: …]. Please determine whether there exists a target exception case whose cause is consistent with the current business exception and whose handling solution is reusable. If it exists, output the case ID; otherwise, output 'No match'."

[0048] If the output of the first language model indicates the existence of a target exception case, it means that there are available historical cases in the knowledge base. Therefore, step S250 can be executed: if a target exception case exists, the first handling solution for the target exception case can be used to handle the business exception. That is, the first handling solution for the target exception case can be applied to the current business exception.

[0049] If no target anomaly case exists, it indicates that no usable historical cases exist in the knowledge base. In some embodiments of this specification, corresponding handling methods are proposed for the case where no target anomaly case exists.

[0050] In some embodiments, when no target exception case exists, i.e., no available historical cases exist in the knowledge base, a second processing solution for the business exception can be generated using the second language model, and this second processing solution can be used to handle the business exception. The second processing solution can be considered as a recommended processing solution generated by the second language model for the business exception. For example, a prompt can be constructed based on the exception description of the business exception (e.g., related log information found based on the traceID of the business exception), and the constructed prompt can be input into the second language model, which will then generate a recommended second processing solution. Thus, even when no available historical cases exist in the knowledge base, the natural language understanding and generation capabilities of the second language model can be utilized to generate a recommended second processing solution.

[0051] In some embodiments, a preset set of error types can be pre-constructed. This preset set includes multiple second error types. Each second error type has a corresponding third processing scheme. The third processing scheme is a customized processing strategy set for the second error type. In the absence of a target exception case, i.e., when there are no available historical cases in the knowledge base, it can be determined whether there is a second error type in the preset set that matches the first error type of the business exception; that is, whether the first error type of the business exception belongs to one of the second error types in the preset set. If a second error type matching the first error type exists, the third processing scheme corresponding to that second error type is used to handle the business exception. Therefore, even when there are no available historical cases in the knowledge base, the pre-defined third processing scheme can be used to handle the business exception based on its second error type. As mentioned above, the first error type of the business exception can be recorded in logs related to the business exception (such as the associated logs mentioned above). Therefore, the first error type of the business exception can be directly determined based on log information.

[0052] For example, the preset set of error types may include, but is not limited to: image format not supported, video format not supported, and internal service exception. A third processing solution corresponding to image format not supported may include: returning a first error code. A third processing solution corresponding to video format not supported may include: returning a second error code. A third processing solution corresponding to internal service exception may include: modifying the resource configuration of the service handling the business request corresponding to the business exception (e.g., increasing the capacity of computing, storage, or network resources), and reprocessing the business request based on the modified resource configuration.

[0053] In some embodiments, if no target exception case exists, i.e., no available historical cases exist in the knowledge base, it can first be determined whether a second error type consistent with the first error type of the business exception exists in the preset error type set. If a second error type consistent with the first error type exists, the third processing solution corresponding to the second error type consistent with the first error type is used to handle the business exception. If no second error type consistent with the first error type exists, a second processing solution for the business exception is generated using the second large language model, and the second processing solution is used to handle the business exception. Thus, the processing solution of the historical case matching the business exception in the knowledge base can be used first to handle the exception; if no matching historical case exists in the knowledge base, the processing solution corresponding to the second error type consistent with the first error type of the business exception is used; if neither a matching historical case nor a second error type consistent with the first error type of the business exception exists in the knowledge base, a fallback solution based on the large model is executed, i.e., a recommended processing solution is generated using the second large language model.

[0054] In some embodiments, upon successful handling of a business exception, a second embedded representation of the business exception can be generated using an embedding model and stored in a vector database. That is, if the handling result of a business exception is successful (e.g., business recovery), this business exception can be stored as a successful exception case in the knowledge base (i.e., the vector database). For example, the text information of the business exception can be split into multiple text segments, and a second embedded representation of the text can be generated using an embedding model. The text information may include an exception description and a handling solution for the business exception. The exception description may include, but is not limited to, related logs found based on the traceID of the business exception. Thus, each successful exception handling result can be automatically fed back to the knowledge base, which can continuously evolve without intervention, ensuring that the latest historical data can be called during real-time processing, achieving a closed loop of "exception handling - knowledge accumulation - automatic optimization".

[0055] Figure 3 This is an overall flowchart of business exception handling in one embodiment of this specification.

[0056] See Figure 3 The entire business process includes a knowledge base update process and a business exception handling process. The knowledge base update process includes... Figure 3 Steps S301 to S303 in the process. The business exception handling procedure includes... Figure 3 Steps S310 to S352 in the process.

[0057] The knowledge base update process is described below.

[0058] In step S301, historical data is extracted periodically.

[0059] For example, a timed event can be triggered daily at 2:00 AM to retrieve exception alerts, logs, and handling solutions associated with traceids from the historical database, covering all historical exception cases. These historical exception cases in the database can include those that were ultimately marked as successful in the business exception handling process.

[0060] In step S302, data is cleaned and vectorized.

[0061] Clean invalid logs, removing duplicate / noisy data. Split the text, including anomaly descriptions and handling solutions, into document slices. Generate vectors (corresponding to the second embedding representation mentioned above) using a fixed embedding model (such as bge-m3 or qwen3-embedding). Attach metadata (error type, handling result, timestamp) to each text segment. The anomaly description can include anomaly alerts and logs associated with the traceid. Optionally, the anomaly description can also include manually set descriptive text about the anomaly.

[0062] In step S303, the knowledge base is updated.

[0063] After data cleaning and vectorization, the vectorization results can be stored in a vector database (such as Milvus). Version identifiers (e.g., v20250704) and update timestamps can also be generated for the vectors stored in the database. Both the version identifier and update time can be considered metadata for the vector (or the text associated with the vector).

[0064] The knowledge base update process corresponds to the RAG write chain mentioned above. Figure 4 This is a data processing flowchart of the RAG write link in one embodiment of this specification. Figure 4 It fully presents the automated construction process from raw operation and maintenance data to a structured vector knowledge base.

[0065] See Figure 4RAG writes to the historical database. The historical database stores the original records of all historical business anomalies, including the traceID for each anomaly, full-link logs (covering request entry points, intermediate service calls, error stacks, etc.), manual alerts, and effective handling solutions confirmed by operations and maintenance personnel.

[0066] In step S410, raw anomaly data is extracted from the historical database at regular intervals. For example, the system triggers a data extraction operation at 2:00 AM every day through a scheduled task, selecting only anomaly cases whose processing results are marked as "successful" to ensure the quality and reusability of the knowledge base content.

[0067] In step S420, the data cleaning stage begins.

[0068] First, noisy data such as debugging information, duplicate error entries, and non-compliant formats are filtered out from the logs. Second, the logs are standardized, for example, by unifying the time format and normalizing error code representations (e.g., mapping "FFmpeg decodefailed" to "video decoding failed"), to improve subsequent semantic consistency. The cleaned data forms structured anomaly records, each containing the following fields: traceID, original request content, error type (labeled by rules or manually), system resource status (CPU / GPU / memory usage), processing solution text, and the identifier of the person handling the error.

[0069] In step S430, a text slicing operation is performed to avoid diluting key information with long text.

[0070] For example, the "anomaly description" (generated from the end-to-end log summary) in each record can be concatenated with the "handling plan", and the long text can be segmented to obtain multiple text fragments.

[0071] For example, the "anomaly description" (generated from the end-to-end log summary) and "handling solution" in each record can also be split into two independent semantic units. For instance, a record might be split into segment 1: "User uploads HEIC image, service A fails to call image parsing module, returns 'unsupported format'" and segment 2: "Returns HTTP 400 error code, and prompts 'only JPEG / PNG format is supported'".

[0072] In step S440, metadata is appended to each text fragment.

[0073] Metadata may include: (1) error type label (e.g., “image format not supported”); (2) processing result (success); (3) timestamp (time of occurrence of the error and time of entry into the database); (4) traceID (used for tracing the source).

[0074] In step S450, the text fragment with metadata is fed into the Embedding model.

[0075] The embedding model can use a fixed version of the bge-m3 or qwen3-embedding model to ensure vector space consistency. The embedding model converts text fragments into 768-dimensional dense vectors while preserving the original metadata.

[0076] In step S460, a globally unique version identifier is generated for this batch update.

[0077] Version identifiers can be used to specify the use of a particular version of the vector database in online services, preventing instability in online behavior due to sudden changes in the vector database. For example, a version identifier could be v20250704. Finally, the vectors with version identifiers and their metadata are stored as key-value pairs in the vector database (such as Milvus).

[0078] Thus, the entire RAG write chain achieves the automated accumulation of unstructured, scattered operational experience into a high-quality, searchable vector knowledge base with contextual semantics, providing a reliable data foundation for the read chain.

[0079] The exception handling query process is described below. This specification's embodiments design differentiated handling processes for different types of errors, categorizing errors into four types (formatting issues, internal service exceptions, matching historical cases, and other exceptions), each employing a customized handling strategy. Furthermore, the priority of these four error types is: matching historical cases > formatting issues = internal service exceptions > other exceptions. The handling strategy for other exceptions, as a safety net, involves explicit handling suggestions provided by the overall model, possessing higher reliability.

[0080] In step S310, a new service exception is triggered. A new service exception trigger refers to a new exception that occurs during service operation.

[0081] In step S315, an alarm and related logs are generated. In response to the triggering of a new business anomaly, an alarm and related logs (including traceid) can be automatically generated. The log structure may include, but is not limited to, the original query, error type, system status, and timestamp. Related logs refer to log information generated at all stages of the business chain related to this anomaly by searching the log system using the traceid as the keyword.

[0082] In step S320, historical data is retrieved.

[0083] You can access the knowledge base to retrieve the Top-K (e.g., K=3) most similar historical cases. The retrieval process can be found in the above text. Figure 2The description of steps S210 to S230 in the text.

[0084] In step S325, the large model analysis is invoked.

[0085] After retrieving the Top-K most similar historical cases, the large model (corresponding to the first large language model mentioned above) can be invoked to analyze whether there are any cases among these Top-K most similar historical cases that match the anomaly to be processed. The implementation process of invoking the large model for analysis can be found in the above-mentioned combination of... Figure 2 The description of step S240 is as follows. For example, when the large model outputs analysis results, such as historical cases that match anomalies, it can also output metadata related to those historical cases to enhance the reliability and verifiability of the results.

[0086] If a historical case matching the exception exists, proceed to step S330 and apply a similar handling method to process the exception.

[0087] If no historical cases match the exception, proceed to step S340 to determine the error type.

[0088] If the error type is "image format not supported," then execute step S345, directly returning error code 400 (image format not supported), and execute step S352 to mark the process as failed. If the error type is "video format not supported," then execute step S346, directly returning error code 415 (video format not supported), and execute step S352 to mark the process as failed. In cases of format-related errors such as "image format not supported" or "video format not supported," the user needs to handle the error, for example, by uploading correctly formatted image or video data. Therefore, only the corresponding error code needs to be output. Returning (i.e., outputting) the corresponding error code for format issues does not truly resolve the format problem and restore business operations. Therefore, after returning the corresponding error code, the process can be marked as failed so that this error type is not subsequently stored as a historical case in the knowledge base. This can be understood as format-related errors requiring user handling, and there is no corresponding solution that can truly resolve the format problem.

[0089] If the error type is an internal service exception (e.g., insufficient memory / computing power), then execute steps S341 and S342 sequentially to initiate manual scaling and restart the task. Manual scaling refers to the ability of system administrators or operations personnel to manually increase system resources (such as servers, storage, network bandwidth, etc.). Optionally, automatic scaling can also be achieved by using operations tools. After restarting the task, execute step S343 to check the execution status. If the execution status is successful, execute step S351 to mark the process as successful. If the execution status is failed, execute step S352 to mark the process as failed.

[0090] If the error type is another type, proceed to step S347, invoking the large model to generate heuristic handling suggestions (such as "suggest checking GPU driver version"), and return them to the operations and maintenance personnel. In step S348, based on the execution result of step S347, determine if an executable solution exists; for example, determine if the large model provides a practically usable handling solution. If an executable solution exists, proceed to step S351, marking the process as successful. Otherwise, if no executable solution exists, proceed to step S352, marking the process as failed. The exceptions marked as successful and their handling solutions can be added to the knowledge base as historical data through steps S301 to S303, ensuring that the latest historical data can be used when handling exceptions in real time.

[0091] The exception handling query process corresponds to the RAG read link mentioned above. Figure 5 This is an interactive timing diagram of the RAG read link in one embodiment of this specification. Figure 5 It accurately depicts the collaboration logic, data flow, and temporal dependencies of each component when a new anomaly occurs.

[0092] See Figure 5 The process begins at step S511, when the business system detects a new anomaly (such as API call timeout, format validation failure, etc.). The system immediately generates an alarm event containing a unique traceID and sends a query request to the log system.

[0093] In step S521, the log system aggregates the logs of all related services on the distributed call chain (including upstream request parameters, intermediate service status, and downstream error stack) based on the traceID, and returns complete end-to-end related logs to ensure that no information is missing from the exception context (for example, service B reports an error "out of memory", but the root cause is that service A sent an extremely large image, and the location cannot be found by relying solely on the logs of service B).

[0094] In step S512, after receiving the end-to-end log, the business system uses it as input to feed into the same embedding model as the RAG write link to generate a first embedding representation, and then uses the first embedding representation to initiate an approximate nearest neighbor (ANN) retrieval to the vector database. In step S531, the vector database returns the Top-K most similar historical cases (K defaults to 3), each case containing its text fragment, processing scheme, and metadata (such as error type and timestamp).

[0095] To avoid misjudgments due to semantically similar but causal differences caused by relying solely on vector similarity (e.g., two "insufficient memory" cases, one due to excessive model size and the other due to excessive concurrency, with drastically different handling solutions), the system executes step S513 to construct a structured prompt: "Current anomaly log: <full-link log>; Candidate historical cases: [Case 1: <log + solution>, Case 2: …]. Please determine if there is a target case with the same root cause and a reusable handling solution. If it exists, output the case ID; otherwise, output 'no match'." The prompt is then input into the first large language model (LLM1) to call LLM1 to determine if a matching target case exists.

[0096] If LLM1 executes step S541 and returns a valid case ID, then the business system executes step S514 and directly executes the processing plan for the target case (such as automatic configuration rollback, retrying requests, etc.).

[0097] If LLM1 returns "no match", then the hierarchical fallback mechanism is activated.

[0098] First, the business system's built-in preset rule engine executes step S551 to parse the error type of the current exception. This error type can be extracted from log keywords (such as "unsupported image format") or system status (such as GPU memory usage > 95%). If the error type belongs to a preset type, step S552 is executed to return the corresponding processing strategy. Taking the preset error type set including "image format not supported", "video format not supported", and "service internal exception" as an example, if the error type belongs to the first two, the standard HTTP error code (400 / 415) is returned directly; if the error type belongs to "service internal exception", the business system can execute step S515 to call the operation and maintenance tool interface and perform three steps: "expand resource configuration → restart task → check execution status" (for example, increasing the container CPU from 2 cores to 4 cores, restarting the Pod, and polling the task status until success or timeout). If the error type is not covered by the preset rules (e.g., a new dependency library conflict), meaning the error type does not belong to the preset type, the business system executes step S516, inputting the current log into the second largest language model (LLM2) to call LLM2 to generate natural language suggestions (e.g., "It is recommended to upgrade libavcodec to v58.134 or higher"). LLM2 executes step S571 and returns the natural language suggestions. After receiving the natural language suggestions returned by LLM2, the business system executes step S517, pushing the suggestions to the operations and maintenance terminal (Ops) for manual decision-making.

[0099] Regardless of the processing path, as long as the business anomaly is successfully resolved (e.g., the service returns to normal response), the system can execute step S518 to automatically initiate the feedback process: package the full-link log of this anomaly, the final handling solution adopted, the error type, and the handling result, and then... Figure 4 The write process shown is sliced, vectorized, and stored in a vector database to complete the knowledge loop. Figure 5 The sequence diagram shown not only demonstrates the collaborative decision-making mechanism of multiple models and strategies, but also emphasizes the contextual integrity driven by traceID, the causal verification role of large models, the priority integration of rules and AI, and the self-evolutionary capability of automatic feedback. Together, these constitute the core technology for solving the three major pain points of "low efficiency, narrow coverage, and scattered knowledge".

[0100] Thus, combined Figures 2 to 5 The document provides a detailed explanation of the business exception handling process.

[0101] This specification also provides a computing device in its embodiments, including a memory and a processor. The memory stores computer programs / instructions, and when the processor executes the computer programs / instructions, it implements the methods in the foregoing embodiments.

[0102] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0103] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0104] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0105] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0106] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0107] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will 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 program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0108] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0111] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0112] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0113] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0114] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0115] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0116] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for handling business exceptions, comprising: Obtain a first embedded representation of the business exception, which is generated based on the description information of the business exception; Calculate the similarity between the first embedding representation and each of the second embedding representations in at least a portion of the second embedding representations in the vector database, wherein the second embedding representation is an embedding representation of at least a portion of the text of the anomalous case; Select the top number of abnormal cases based on similarity ranking; The first language model is used to determine whether there is a target abnormal case that matches the business abnormality among the first number of abnormal cases; In the event of the aforementioned target exception case, the first handling scheme for the target exception case shall be used to handle the business exception.

2. The method according to claim 1, wherein, The method further includes: In the absence of the target exception case, a second handling solution for the business exception is generated using the second largest language model; The second processing solution is used to handle the business exception.

3. The method according to claim 1, wherein, If the target exception case does not exist, determine whether there is a second error type in the preset error type set that is consistent with the first error type of the business exception. Each second error type has a corresponding third processing solution. If a second error type that is consistent with the first error type exists, the third processing scheme corresponding to the second error type that is consistent with the first error type shall be used to handle the business exception.

4. The method according to claim 1, wherein, The method further includes: In the absence of the target anomaly case, determine whether there is a second error type in the preset error type set that is consistent with the first error type of the business anomaly, wherein each second error type has a corresponding third processing solution; If a second error type that is consistent with the first error type exists, the third processing scheme corresponding to the second error type that is consistent with the first error type shall be used to handle the business exception; If no second error type exists that matches the first error type, a second processing solution for the business exception is generated using the second largest language model, and the business exception is processed using the second processing solution.

5. The method according to claim 3 or 4, wherein, The preset set of error types includes: image format not supported, video format not supported, and internal service exception. The third processing solution corresponding to the image format not being supported includes: returning a first error code. The third processing solution corresponding to the video format not being supported includes: returning a second error code. The third handling scheme corresponding to the internal service exception includes: modifying the resource configuration of the service that handles the business request corresponding to the business exception, and reprocessing the business request based on the modified resource configuration.

6. The method according to claim 1, wherein, Obtain the first embedded representation of the business exception, including: Retrieve log information associated with the trace identifier of the business anomaly; Generate a first embedded representation of the log information.

7. The method according to claim 1, wherein, Using the first major language model, determine whether there is a target anomaly case matching the business anomaly among the first number of anomaly cases, including: Based on the description information of the business anomaly, the description information of each anomaly case in the first number of anomaly cases, and the processing plan, a first input prompt is generated. The first input prompt is input into the first large language model to obtain the judgment result output by the first large language model. The first input prompt instructs the first large language model to determine whether there is a target anomaly case in the first number of anomaly cases whose anomaly cause is consistent with the business anomaly.

8. The method according to any one of claims 1 to 7, wherein, The method further includes: If the business exception is successfully handled, a second embedded representation of the business exception is generated using the embedding model, and the second embedded representation is stored in the vector database.

9. The method according to claim 8, wherein, Generating a second embedded representation of the business anomaly using an embedding model includes: The text information of the business exception is split into multiple text segments, which include an exception description of the business exception and a handling solution. A second embedded representation of the text is generated using an embedding model.

10. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-9.

Images