Call bill anomaly analysis method and device, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a call ticket exception analysis method and device, electronic equipment and a readable storage medium. The method comprises the steps of obtaining a target business scene corresponding to a to-be-analyzed call ticket file; based on a target vector database corresponding to the target business scene, performing retrieval matching with the telephone bill vector data corresponding to the to-be-analyzed telephone bill file to obtain a reason analysis result; under the condition that a matching value in the reason analysis result is greater than a preset threshold value, determining a target abnormal reason corresponding to the to-be-analyzed ticket file based on an abnormal reason corresponding to the matching value; and under the condition that the matching value is smaller than or equal to a preset threshold value, determining a target abnormal reason corresponding to the to-be-analyzed ticket file according to a target troubleshooting path corresponding to the target business scene. By combining the efficient retrieval capability of the vector database and the comprehensive troubleshooting mode based on the target troubleshooting path, manual intervention for anomaly analysis is avoided, and the call ticket anomaly analysis efficiency is improved in an automatic mode while the anomaly reason can be positioned more accurately.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a call bill anomaly analysis method, device, electronic device and readable storage medium. Background Art

[0002] With the continuous advancement of science and technology, the communications industry has become increasingly important in people's lives. With the popularization of mobile Internet, communication users generate a large number of communication call records when using communication services.

[0003] In related technologies, during the call record data matching process, users may not be accurately matched or user information may be inconsistent, resulting in abnormal call record and user matching. For call records with user matching anomalies, various data tables in the service system, such as the mobile number table, mobile code table, and mobile IMSI table, are often traversed to comprehensively determine the cause of the anomaly. However, this anomaly analysis method requires manual intervention for comprehensive analysis, which is inefficient. Summary of the Invention

[0004] In order to overcome the problems existing in the related art, the present invention provides a call record abnormality analysis method, device, electronic device and readable storage medium.

[0005] In a first aspect, the present invention provides a method for analyzing call record anomalies, the method comprising:

[0006] Obtain the target business scenario corresponding to the call record file to be analyzed;

[0007] Performing a search and matching based on the target vector database corresponding to the target business scenario and the call record vector data corresponding to the call record file to be analyzed to obtain a cause analysis result;

[0008] When the matching value in the cause analysis result is greater than a preset threshold, determining the target abnormal cause corresponding to the call record file to be analyzed based on the abnormal cause corresponding to the matching value;

[0009] When the matching value is less than or equal to the preset threshold, the target abnormality cause corresponding to the call record file to be analyzed is determined according to the target troubleshooting path corresponding to the target business scenario.

[0010] Optionally, the method further includes:

[0011] When the different network judgment number segment of the call record file to be analyzed meets the different network judgment condition corresponding to the target service scenario, determining that the target abnormality cause corresponding to the call record file to be analyzed is the first abnormality cause;

[0012] When any data of the first data type in the call record file to be analyzed is a null value, determining that the target abnormal cause corresponding to the call record file to be analyzed is a second abnormal cause;

[0013] When any data of the second data type in the call record file to be analyzed does not satisfy the data format corresponding to the second data type, the target abnormal cause corresponding to the call record file to be analyzed is determined to be a third abnormal cause.

[0014] Optionally, determining a target abnormality cause corresponding to the call record file to be analyzed according to a target troubleshooting path corresponding to the target business scenario includes:

[0015] Based on the target business scenario, determining a target troubleshooting path corresponding to the target business scenario; the target troubleshooting path is defined by multiple business nodes and a business node topology corresponding to each of the business nodes;

[0016] The exception handling node corresponding to the target business scenario is called, and according to the troubleshooting order indicated by the business node topology, the target exception cause corresponding to the call record file to be analyzed is determined in the business database corresponding to each business node.

[0017] Optionally, after determining a target troubleshooting path corresponding to the target business scenario based on the target business scenario, the method further includes:

[0018] Determining a target weight value corresponding to the target troubleshooting path based on a weight coefficient corresponding to each of the service nodes in the target troubleshooting path;

[0019] Determining a processing order corresponding to the call record files to be analyzed based on the target weight value, the number of service nodes in the target troubleshooting path, and the average troubleshooting time corresponding to the target troubleshooting path;

[0020] The calling of the exception handling node corresponding to the target business scenario includes:

[0021] When the processing sequence corresponding to the call record file to be analyzed is reached, the exception processing node corresponding to the target business scenario is called.

[0022] Optionally, after determining the target abnormality cause corresponding to the call record file to be analyzed according to the target troubleshooting path corresponding to the target business scenario, the method further includes:

[0023] The target abnormality cause and the call record vector data are stored correspondingly in a target vector database corresponding to the target business scenario.

[0024] Optionally, the method further includes:

[0025] Acquire multiple historical call record data corresponding to at least two business scenarios and call unit data corresponding to each of the historical call record data;

[0026] For any business scenario, performing vector conversion on multiple historical call record data corresponding to the business scenario to obtain multiple historical vector data;

[0027] Based on the historical vector data and call unit data of each of the historical call record data corresponding to the business scenario, a vector database corresponding to the business scenario is constructed.

[0028] In a second aspect, the present invention provides a device for analyzing call record anomalies, the device comprising:

[0029] The first acquisition module is used to obtain the target business scenario corresponding to the call record file to be analyzed;

[0030] A first matching module is configured to perform a search and match based on a target vector database corresponding to the target business scenario and call record vector data corresponding to the call record file to be analyzed, to obtain a cause analysis result;

[0031] A first determining module is configured to determine, when a matching value in the cause analysis result is greater than a preset threshold, a target abnormal cause corresponding to the call record file to be analyzed based on the abnormal cause corresponding to the matching value;

[0032] The second determination module is used to determine the target abnormality cause corresponding to the call record file to be analyzed according to the target troubleshooting path corresponding to the target business scenario when the matching value is less than or equal to the preset threshold.

[0033] Optionally, the device further comprises:

[0034] A third determination module is configured to determine that the target abnormality cause corresponding to the call record file to be analyzed is a first abnormality cause when the different network judgment number segment of the call record file to be analyzed meets the different network judgment condition corresponding to the target business scenario;

[0035] A fourth determining module is configured to determine that the target abnormality cause corresponding to the call record file to be analyzed is a second abnormality cause when any data of the first data type in the call record file to be analyzed is a null value;

[0036] The fifth determination module is used to determine that the target abnormal cause corresponding to the call record file to be analyzed is the third abnormal cause when any data of the second data type in the call record file to be analyzed does not meet the data format corresponding to the second data type.

[0037] Optionally, the second determining module includes:

[0038] A first determination submodule is configured to determine a target troubleshooting path corresponding to the target business scenario based on the target business scenario; the target troubleshooting path is defined by a plurality of business nodes and a business node topology corresponding to each of the business nodes;

[0039] The first calling module is used to call the exception handling node corresponding to the target business scenario, and determine the target exception cause corresponding to the call record file to be analyzed in the business database corresponding to each business node according to the troubleshooting order indicated by the business node topology.

[0040] Optionally, the device further comprises:

[0041] a sixth determining module, configured to determine a target weight value corresponding to the target troubleshooting path based on a weight coefficient corresponding to each of the service nodes in the target troubleshooting path;

[0042] a seventh determining module, configured to determine a processing order corresponding to the call record file to be analyzed based on the target weight value, the number of service nodes in the target troubleshooting path, and the average troubleshooting time corresponding to the target troubleshooting path;

[0043] The first calling module includes:

[0044] The first calling submodule is used to call the exception processing node corresponding to the target business scenario when the processing sequence corresponding to the call record file to be analyzed is reached.

[0045] Optionally, the device further comprises:

[0046] The first storage module is used to store the target abnormality cause and the call record vector data in a target vector database corresponding to the target business scenario.

[0047] Optionally, the device further comprises:

[0048] A second acquisition module is used to obtain a plurality of historical call record data corresponding to at least two business scenarios and call unit data corresponding to each of the historical call record data;

[0049] A first conversion module is configured to perform vector conversion on a plurality of historical call record data corresponding to any business scenario to obtain a plurality of historical vector data;

[0050] The first construction module is used to construct a vector database corresponding to the business scenario based on the historical vector data and the call unit data of each of the historical call record data corresponding to the business scenario.

[0051] In a third aspect, the present invention provides an electronic device comprising: a processor, a memory, and a computer program stored on the memory and runnable on the processor, wherein the processor implements the call record anomaly analysis method described in any one of the first aspects above when executing the program.

[0052] In a fourth aspect, the present invention provides a readable storage medium. When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the steps in the call record anomaly analysis method in any embodiment of the first aspect above.

[0053] In an embodiment of the present invention, the target business scenario corresponding to the call record file to be analyzed is obtained; a target vector database corresponding to the target business scenario is searched and matched with the call record vector data corresponding to the call record file to be analyzed to obtain a cause analysis result; when the matching value in the cause analysis result is greater than a preset threshold, the target abnormal cause corresponding to the call record file to be analyzed is determined based on the abnormal cause corresponding to the matching value; when the matching value is less than or equal to the preset threshold, the target abnormal cause corresponding to the call record file to be analyzed is determined according to the target investigation path corresponding to the target business scenario. In this way, by processing the call record data in a vectorized manner, the complex features and potential associations in the call record data can be captured, thereby improving the accuracy and sensitivity of abnormality analysis. Furthermore, when the matching value is greater than the preset threshold, the system can automatically and quickly determine the target abnormal cause based on the abnormal cause corresponding to the matching value, shortening the abnormality analysis time and improving operational efficiency. When the matching value does not reach the preset threshold, further investigation is automatically performed according to the target investigation path corresponding to the target business scenario, ensuring the comprehensiveness and in-depth nature of the abnormality investigation. By combining the efficient retrieval capabilities of the vector database with a comprehensive investigation method based on the target investigation path, manual intervention in anomaly analysis is avoided. While being able to more accurately locate the cause of the anomaly, the efficiency of call record anomaly analysis is improved in an automated manner. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0055] Figure 1 This is a flowchart of a method for analyzing call log anomalies provided by an embodiment of the present invention;

[0056] Figure 2 This is a flowchart of a search and matching method provided by an embodiment of the present invention;

[0057] Figure 3 This is a flowchart of specific steps for analyzing call record anomalies provided by an embodiment of the present invention;

[0058] Figure 4 This is a flowchart of specific steps for another call record abnormality analysis provided by an embodiment of the present invention;

[0059] Figure 5 This is a structural diagram of a call record anomaly analysis device provided by an embodiment of the present invention;

[0060] Figure 6 This is a structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0061] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0062] Figure 1 This is a flowchart of a method for analyzing call log anomalies provided by an embodiment of the present invention. Figure 1 As shown, the method may include:

[0063] Step 101: Obtain the target business scenario corresponding to the call record file to be analyzed.

[0064] In the embodiment of the present invention, the call record file to be analyzed may be original call record data collected from various communication nodes or network elements, or may be a call record file that has been pre-processed and has been judged to have a user matching anomaly.

[0065] For example, the original call bill data can be collected, parsed and pre-processed in advance by the collection and pre-processing center. First, the call bills of various network elements are collected, the necessary field information in the call bill data is parsed, the business scenario is determined based on the necessary information, and pre-processing judgment is performed to output normal and various abnormal call bills. Abnormal call bills can include abnormal call bills of different abnormal types, such as abnormal call bills of user matching abnormal types. Abnormal call bills of different abnormal types can be marked with different error codes. Abnormal call bills of user matching abnormal types refer to situations where, when processing a communication call bill, a communication operator finds that it cannot match the user, account or package information associated with it, resulting in the communication call bill being unable to be correctly classified or processed. This type of matching abnormal call bill may cause the operator or communication service provider to be unable to accurately process or count customer usage. Then, it can be filtered according to the error code of the abnormal type that matches the user. For call bill data that does not match the abnormal type that matches the user, it is directly added to the abnormal call bill library, and the call bill data of the user matching abnormal type is used as the call bill file to be analyzed. Since the error codes and error descriptions of the abnormal call records output by the procurement center that match the users are highly localized and professional, the embodiment of the present invention conducts further detailed analysis and accurately locates the causes of the abnormalities on the call records whose abnormality types are user matching abnormalities and have been analyzed and output by the procurement center.

[0066] The call record file to be analyzed records various information about the user during the communication process. Based on the specified fields in the call record file to be analyzed, the target business scenario corresponding to the call record file to be analyzed is determined. Different specified fields in the call record file can be used to represent different business scenarios, which can include voice scenarios, Internet scenarios, SMS scenarios, and value-added service scenarios. Voice scenarios mainly refer to voice calls made by users through communication devices (such as mobile phones and landlines). Internet scenarios mainly refer to the behavior of users accessing the Internet through mobile devices (such as smartphones and tablets) for data transmission. SMS scenarios mainly refer to the behavior of users sending and receiving text messages through the SMS function. Value-added service scenarios mainly refer to the additional services provided by operators in addition to basic communication services. These value-added services can usually be expanded and innovated based on the communication needs of users.

[0067] Step 102: Search and match the target vector database corresponding to the target business scenario with the call record vector data corresponding to the call record file to be analyzed to obtain a cause analysis result.

[0068] In an embodiment of the present invention, a corresponding vector database is constructed for different business scenarios. The vector database corresponding to each business scenario contains historical vector data and call unit data corresponding to the historical abnormal call records corresponding to each business scenario. The call unit data is used to describe other data information of the historical vector data for easy retrieval and management. The call unit data may include the cause of the abnormality, the type of business scenario, the business troubleshooting path, the detailed cause, and remarks, etc. The target vector database is a vector database corresponding to the target business scenario, and the target vector database contains historical vector data corresponding to multiple abnormal call records whose business scenario is the target business scenario and call unit data corresponding to multiple abnormal call records.

[0069] The call record file to be analyzed is converted into a vector to obtain call record vector data. The call record file to be analyzed is divided into multiple units, such as sentences or phrases, according to preset labels corresponding to the target business scenario. Feature extraction or embedding methods are then used to convert the pre-processed call record data into vectors. Different business scenarios correspond to different preset labels. When the business scenario is a voice scenario, the preset labels may include service type, calling and called numbers, call time and duration, switch, base station, peer number type, domestic long-distance area code, and international long-distance area code. When the business scenario is an Internet scenario, the preset labels may include service type, calling number, Internet access method, Internet time, Internet duration, base station, uplink and downlink traffic, domestic long-distance area code, and international operator code. When the business scenario is an SMS scenario, the preset labels may include service type, calling and called numbers, sending time, receiving time, domestic long-distance area code, international long-distance area code, SMS identifier, and international operator code. When the business scenario is a value-added service scenario, the preset labels may include service type, calling number, subscription time, service provider code, product name, subscription fee, and monthly subscription identifier. The text in the call record file to be analyzed is segmented according to the preset labels to obtain feature text corresponding to different preset labels. The feature text is then converted into a vector to obtain call record vector data. The call record vector data may include label vectors corresponding to multiple preset labels. Exemplarily, a word embedding model (such as Word2Vec, GloVe, etc.) can be used to convert the text into a vector, or a deep learning model (such as BERT, Transformer, etc.) can be used to extract feature vectors. It will be understood that the embodiment of the present invention does not limit the method of vector conversion.

[0070] The call record vector data corresponding to the call record file to be analyzed is retrieved and matched based on the target vector database to obtain the cause analysis result. Based on the similarity algorithm, the historical vector data matching the call record vector data is retrieved in the target vector database by determining the matching value of each historical vector data and the call record vector data, and the speech unit data corresponding to the historical vector data is determined as the cause analysis result. That is, the cause analysis result may include the abnormal cause and matching value in the speech unit data corresponding to the matched historical vector data. The matching value is used to characterize the similarity between the historical vector data and the call record vector data. Exemplarily, the matching value between the call record vector data and the historical vector data can be calculated based on a similarity algorithm such as Euclidean distance, cosine similarity or Hamming distance by calling the automatic analysis Agent (agent executor) service.

[0071] The retrieval and matching process can be as follows: based on all call record vector data corresponding to the call record file to be analyzed, that is, the feature vectors corresponding to each preset label, a complete match is performed with the historical vector data in the target vector database (the historical vector data also includes historical feature vectors corresponding to multiple preset labels). Based on the matching values corresponding to the call record vector data and each historical vector data, the matching value that meets the retrieval criteria and the corresponding call unit data of the historical vector data are determined as the cause analysis result. The retrieval criteria can include the maximum matching value, the first m matching values after sorting the matching values from largest to smallest, etc.

[0072] Or, based on the partial call record vector data corresponding to the call record file to be analyzed, match it with the partial feature vectors corresponding to the historical vector data in the target vector database. Since the key factors affecting the cause of abnormalities in historical abnormal call records of different business scenarios are often similar, for example, in a voice scenario, if the main called number and the called number of the abnormal call records of two users matching the abnormal type are the same, then the abnormal causes corresponding to the two abnormal call records are likely to be the same. Therefore, in order to simplify the matching process and improve the matching efficiency, the feature vector corresponding to the specified label corresponding to the target business scenario in the call record vector data can be matched with the historical feature vector corresponding to the specified label in the target vector database, and according to the matching value of the feature vector corresponding to the specified label and the historical feature vector, the matching value that meets the retrieval condition and the corresponding historical vector data are determined as the cause analysis result. Among them, the retrieval condition can be the maximum matching value, the first m values after the matching values are arranged from large to small, etc. When the service scenario is a voice scenario, the designated tag can be the calling number or the called number; when the service scenario is an Internet access scenario, the designated tag can be the calling number and the Internet access method; when the service scenario is an SMS scenario, the designated tag can be the calling number or the called number; when the service scenario is a value-added service scenario, the designated tag can be the calling number and the SP code.

[0073] In one possible implementation, the data class interfaces of different business nodes can be combined to obtain various types of historical call record data and abnormal causes in different business nodes to build a target vector database, and the model can be trained based on the target vector database. By inputting the call record file to be analyzed into the model, the model can search and match based on the target vector database and the call record vector data corresponding to the call record file to be analyzed, and perform abnormal cause classification and similarity calculation on the call record file to be analyzed, thereby obtaining the abnormal cause and matching value output by the model and obtaining the cause analysis result. In this way, the model can automatically interpret the call record file to be analyzed that matches the abnormal type of the user, and intuitively output the precise abnormal cause corresponding to the call record file to be analyzed, that is, the call record of the abnormal type that matches the user, to achieve the analysis effect of real-time, automatic and output of specific cause analysis results, which is convenient for peripheral system personnel to receive and analyze the abnormal cause, and provide data basis for achieving the goal of processing revenue recovery and various system decisions.

[0074] For example, Figure 2 As shown, the call record files to be analyzed are divided by the preset labels corresponding to the target business scenario for vector conversion to obtain call record vector data, which is input into the model. The call record vector data is retrieved and matched with the target vector database corresponding to the target business scenario through the model, and the matching value and the cause of the exception are output.

[0075] Step 103: When the matching value in the cause analysis result is greater than a preset threshold, determine the target abnormal cause corresponding to the call record file to be analyzed based on the abnormal cause corresponding to the matching value.

[0076] In an embodiment of the present invention, when the matching value in the cause analysis result is greater than a preset threshold, it indicates that the semantics of the call record vector data and the historical vector data that matches it are similar. Accordingly, the abnormal cause corresponding to the historical vector data is similar to the abnormal cause corresponding to the call record vector data. Therefore, the abnormal cause corresponding to the matching value greater than the preset threshold can be determined as the target abnormal cause corresponding to the call record file to be analyzed. For example, the abnormal cause in the call unit data in the cause analysis result can be used as the target abnormal cause.

[0077] It can be understood that when the cause analysis result contains one matching value and the corresponding abnormal cause, the matching value can be directly compared with the preset threshold; when the cause analysis result contains at least two matching values and the corresponding abnormal causes, the maximum matching value can be selected for comparison with the preset threshold, and then when the maximum matching value is greater than the preset threshold, the abnormal cause corresponding to the maximum matching value is determined as the target abnormal cause.

[0078] Step 104: When the matching value is less than or equal to the preset threshold, determine the target abnormality cause corresponding to the call record file to be analyzed according to the target troubleshooting path corresponding to the target business scenario.

[0079] In an embodiment of the present invention, when the matching value is less than or equal to a preset threshold or the cause analysis result is empty, the semantics of the characterization of the call record vector data and the historical vector data matched therewith are not consistent with expectations. Therefore, an alarm message can be automatically generated and an intervention mechanism can be triggered. The target abnormality cause corresponding to the call record file to be analyzed is automatically determined according to the target troubleshooting path corresponding to the target business scenario through Robotic Process Automation (RPA) technology. According to different business scenarios, it is necessary to conduct cause troubleshooting based on different troubleshooting paths when conducting abnormality troubleshooting. The troubleshooting path can be based on the business nodes involved in the abnormality troubleshooting in different business scenarios and the business node topology composed of each business node. The business point topology is the abnormal call record file processing flow corresponding to different pre-set business scenarios. The business node topology can include the physical and logical relationships between business nodes. Specifically, the physical relationship between business nodes may include the hardware equipment or software systems that each business node needs to call, such as: customer information management routing information system, customer information management user information system and customer information management system, etc.; the logical relationship between business nodes includes the upstream and downstream business nodes corresponding to the troubleshooting process of the business node, for example, 1-if the number length is abnormal, then 2-transfer to the network operation center (network operation) to assist in checking the authenticity of the number.

[0080] According to the target troubleshooting path corresponding to the target business scenario, the database of each business node is traversed and analyzed in turn to determine the target abnormality cause corresponding to the call record file to be analyzed.

[0081] For example, Figure 3 A flowchart showing the specific steps of call list abnormality analysis is shown in FIG. Figure 3 As shown, the target vector database is searched and matched with the call record vector data corresponding to the call record file to be analyzed, obtaining a matching value and anomaly cause. A check is performed to determine whether the matching value exceeds a preset threshold. If so, the anomaly cause corresponding to the matching value is determined as the target anomaly cause. If not, an intervention mechanism is triggered. Based on RPA technology and the target troubleshooting path, the database of each business node is sequentially analyzed to determine the target anomaly cause corresponding to the call record file to be analyzed.

[0082] Optionally, step 104 may include the following steps:

[0083] Step 201: Based on the target business scenario, determine a target troubleshooting path corresponding to the target business scenario; the target troubleshooting path is defined with multiple business nodes and a business node topology corresponding to each of the business nodes.

[0084] In this embodiment of the present invention, corresponding troubleshooting paths are pre-configured for different business scenarios based on their characteristics. The target troubleshooting path defines multiple business nodes and the corresponding business node topology for each business node. For example, in a value-added service scenario, the business nodes may include a customer information management routing data system, a service billing system, and a customer information management user data system.

[0085] Step 202: Call the exception handling node corresponding to the target business scenario, and determine the target exception cause corresponding to the call record file to be analyzed in the business database corresponding to each business node according to the troubleshooting order indicated by the business node topology.

[0086] In an embodiment of the present invention, during the automated troubleshooting process using Robotic Process Automation (RPA) technology, different business scenarios correspond to different exception handling nodes. Multiple call record files to be analyzed are automatically checked in parallel based on these multiple exception handling nodes. The exception handling node corresponding to the target business scenario is invoked by calling the interface corresponding to the target business scenario. Based on the troubleshooting order indicated by the exception handling node according to the business node topology, the service database corresponding to each business node is traversed to determine the target exception cause corresponding to the call record file to be analyzed. For example, the troubleshooting can begin at the source of user information management and proceed stepwise toward downstream business nodes. For example, the troubleshooting order may include the customer information management routing information system, the customer information management user information system, the value-added service platform billing system, and the user authentication and authorization system. First, the customer information management routing information system verifies the accuracy of the user's routing information, including the user's location and access network type, to ensure that this information is consistent with the information recorded in the call record. The customer information management user information system verifies the completeness and accuracy of the user's basic information, such as user number, name, and ID information. This information is the basis for subsequent business processing and must be correct. Check whether the value-added service platform has correctly recorded the user's subscription information and usage history. Also, verify that the interface between the platform and the call billing system is functioning properly to ensure that the call bills accurately reflect the user's VAS usage. Verify that the expense information recorded in the billing system is consistent with the expense information in the call billing system within the service billing system. If any inconsistencies are found, further investigation is required into possible causes, such as billing rules, system vulnerabilities, or human error. Finally, verify that the user's identity and permissions are correctly assigned within the user authentication and authorization system to ensure that the user can access and use the subscribed VAS. Also, check that the interface between the authentication and authorization system and the value-added service platform is functioning properly. Furthermore, traversing the databases of each node can involve extracting relevant data from the databases of each service node, such as basic user information from the user profile system and subscription information and usage history from the value-added service platform. Compare the extracted data with the data in the call bill file to be analyzed to identify inconsistent or abnormal data points. For example, this could involve comparing user numbers, subscription information, and charge information. Conduct in-depth analysis of these inconsistent or abnormal data points to identify possible causes. For example, analyze whether user information is recorded incorrectly, whether there are system vulnerabilities, whether data has been lost or tampered with, etc. Based on the analysis results, determine the specific location of the problem. For example, is the anomaly caused by incorrect user information, a system vulnerability, or data loss?

[0087] In this way, by traversing the databases of each service node and combining the information of the exception handling node with the troubleshooting order of the service node topology, the target anomaly cause for the user matching anomaly corresponding to the call record file to be analyzed can be determined. For example, if a call record mismatch is found to be caused by incorrect user information input, the user can be notified to correct the information; if a call record mismatch is found to be caused by a system vulnerability, the vulnerability can be fixed and the call record regenerated; if a call record mismatch is found to be caused by data loss or tampering, the data can be restored or other appropriate measures can be taken.

[0088] It is understandable that there may be multiple exception processing nodes corresponding to different business scenarios. By managing all exception processing nodes in real time and recording the node status of the exception processing nodes, such as idle / busy / fault, and node resource utilization, automatic troubleshooting tasks can be assigned to each exception processing node based on the node resource utilization (CPU, memory) and task priority of each exception processing node. For example, high-priority call record files to be analyzed can be preferentially allocated to nodes with sufficient idle resources, such as nodes with empty node status and high node resource utilization.

[0089] In an embodiment of the present invention, by determining the target troubleshooting path, clarifying the exception handling nodes, determining the troubleshooting order, traversing the business database corresponding to each business node, and finally determining the cause of the exception, the cause analysis of the call record matching exception can be automatically performed, and the target exception cause of the call record user matching exception can be effectively determined, thereby improving the efficiency of the cause analysis.

[0090] Optionally, after step 201, the embodiment of the present invention may further include the following steps:

[0091] Step 301: Determine a target weight value corresponding to the target investigation path based on the weight coefficient corresponding to each service node in the target investigation path.

[0092] In an embodiment of the present invention, a data-driven method is used to determine the weight ratio of each type of abnormal cause based on historical call record data and the abnormal causes corresponding to each historical call record data, and then the weight of the abnormal cause is determined as the weight of the business node corresponding to the abnormal cause. The business node corresponding to the abnormal cause refers to the business node that causes the abnormal cause, that is, due to an error in the database or other information of the business node, the user matching abnormality occurs. The weight coefficient corresponding to the business node can characterize the probability of occurrence of the abnormal cause that can be caused by the business node. Exemplarily, the weight coefficient corresponding to the business node corresponding to each abnormal cause can be determined based on indicators such as the abnormal occurrence frequency and impact degree of different abnormal causes.

[0093] Based on the weight coefficients corresponding to each service node in the target troubleshooting path, a target weight value corresponding to the target troubleshooting path can be determined. The target weight value can be used to represent the troubleshooting priority and impact of the target troubleshooting path. The larger the target weight value, the higher the priority of the target troubleshooting path and the greater the impact of the target troubleshooting path.

[0094] Step 302: Determine the processing order of the call record files to be analyzed based on the target weight value, the number of service nodes in the target troubleshooting path, and the average troubleshooting time corresponding to the target troubleshooting path.

[0095] Accordingly, step 202 may include the following steps:

[0096] Step 303: When the processing sequence corresponding to the call record file to be analyzed is reached, the exception processing node corresponding to the target business scenario is called.

[0097] In an embodiment of the present invention, when it is necessary to automatically troubleshoot using Robotic Process Automation (RPA) technology and the number of call record files to be analyzed with the same business scenario is at least two, it is necessary to determine the processing order of at least two call record files to be analyzed. Therefore, the processing order corresponding to the call records to be analyzed can be determined based on the target weight value, the number of business nodes in the target troubleshooting path, and the average troubleshooting time corresponding to the target troubleshooting path. The average troubleshooting time corresponding to the target troubleshooting path can be determined based on the average of the historical time spent on troubleshooting based on the target troubleshooting path. The higher the target weight value, the fewer the number of nodes and the shorter the average troubleshooting time, the higher the processing order corresponding to the call record files to be analyzed. For example, you can first make a judgment based on the target weight value. The higher the target weight value, the earlier the processing order of the call record file to be analyzed. If the target weight values are the same, then make a judgment based on the number of nodes. The fewer the number of nodes, the earlier the processing order of the call record file to be analyzed. If the target weight value and the number of nodes are the same, then make a judgment based on the average troubleshooting time. The shorter the average troubleshooting time, the earlier the processing order of the call record file to be analyzed.

[0098] When the processing sequence corresponding to the call record file to be analyzed is reached, the exception processing node corresponding to the target business scenario is called to automatically check the call record file to be analyzed to determine the target exception cause corresponding to the call record file to be analyzed.

[0099] It can be understood that when automatic troubleshooting is required through Robotic Process Automation (RPA) technology and there is only one call record file to be analyzed with the same business scenario, the exception handling node corresponding to the target business scenario can be directly called to automatically troubleshoot the call record file to be analyzed according to the troubleshooting order indicated by the business node topology in the target troubleshooting path to determine the target exception cause corresponding to the call record file to be analyzed.

[0100] In an embodiment of the present invention, the processing order of the call record files to be analyzed is determined based on the target weight value of the target investigation path, the number of service nodes in the target investigation path, and the average investigation time corresponding to the target investigation path. This allows for priority processing of call record file data with high impact and urgency based on the importance of the target investigation path, enabling efficient identification and processing of key anomalies, ensuring the stability of business operations. This processing approach also helps optimize resource allocation, improves the efficiency of anomaly analysis and processing, and thus enhances the overall quality of business operations and user experience.

[0101] In summary, in an embodiment of the present invention, the target business scenario corresponding to the call record file to be analyzed is obtained; the call record vector data corresponding to the call record file to be analyzed is retrieved and matched based on the target vector database corresponding to the target business scenario to obtain the cause analysis result; when the matching value in the cause analysis result is greater than the preset threshold, the target abnormal cause corresponding to the call record file to be analyzed is determined based on the abnormal cause corresponding to the matching value; when the matching value is less than or equal to the preset threshold, the target abnormal cause corresponding to the call record file to be analyzed is determined according to the target investigation path corresponding to the target business scenario. In this way, by processing the call record data in a vectorized manner, the complex features and potential associations in the call record data can be captured, thereby improving the accuracy and sensitivity of the abnormality analysis. Furthermore, when the matching value is greater than the preset threshold, the system can automatically and quickly determine the target abnormal cause based on the abnormal cause corresponding to the matching value, shortening the abnormality analysis time and improving operational efficiency. When the matching value does not reach the preset threshold, further investigation is automatically performed according to the target investigation path corresponding to the target business scenario, ensuring the comprehensiveness and in-depth nature of the abnormality investigation. By combining the efficient retrieval capabilities of the vector database with a comprehensive investigation method based on the target investigation path, manual intervention in anomaly analysis is avoided. While being able to more accurately locate the cause of the anomaly, the efficiency of call record anomaly analysis is improved in an automated manner.

[0102] Optionally, the embodiment of the present invention may further include the following steps:

[0103] Step 401: When the different network judgment number segment of the call record file to be analyzed meets the different network judgment condition corresponding to the target service scenario, determine that the target abnormal cause corresponding to the call record file to be analyzed is the first abnormal cause.

[0104] In an embodiment of the present invention, before performing a search and match based on the target vector database, the call record files to be analyzed can be cleaned. The call record files with the first, second, and third exception reasons can be pre-screened and stored in the database. The first exception reason can be a network anomaly, the second exception reason can be a null value anomaly, and the third exception reason can be a data non-compliance anomaly. Accordingly, data cleaning can include cleaning for network numbers, null values, and compliance.

[0105] In the process of cleaning the different network numbers, when the different network judgment segment of the call record file to be analyzed meets the different network judgment condition corresponding to the target business scenario, the target abnormal cause corresponding to the call record file to be analyzed is determined to be the first abnormal cause. Among them, the different network judgment segment corresponding to the business scenario can be different. The different network judgment segment corresponding to the voice scenario, SMS scenario and value-added scenario is the number segment, and the different network judgment segment corresponding to the Internet scenario is the International Mobile Subscriber Identification Number (IMSI) segment. According to the business scenario of the call record file to be analyzed, the call record file to be analyzed is analyzed to obtain the different network judgment segment corresponding to the call record file to be analyzed. Different business scenarios correspond to different different network judgment conditions, and the different network judgment conditions can be determined based on the operator's own unique standard number segment and standard IMSI segment. For example, the different network judgment condition corresponding to the Internet scenario is that the IMSI segment is 46011. The out-of-network judgment number segment of the call record file to be analyzed is matched with the out-of-network judgment condition corresponding to the target business scenario. When the out-of-network judgment number segment meets the out-of-network judgment condition, it can be determined that the call record file to be analyzed does not belong to the user of this operator. Therefore, the target abnormal cause corresponding to the call record file to be analyzed can be determined as the first abnormal cause, and the call record file to be analyzed is added to the out-of-network abnormal call record database.

[0106] Step 402: When any data of the first data type in the call record file to be analyzed is a null value, determine that the target abnormality cause corresponding to the call record file to be analyzed is a second abnormality cause.

[0107] In an embodiment of the present invention, a call record file to be analyzed contains data information of multiple data types. When the data of the first data type is null, accurate user matching cannot be performed, resulting in a user matching anomaly. Data of the first data type in the call record file to be analyzed is obtained, and a determination is made as to whether the data of the first data type is null. If the data of the first data type is null, this indicates a user matching anomaly caused by the null data value. Therefore, the target anomaly cause corresponding to the call record file to be analyzed can be determined as the second anomaly cause, and the call record file to be analyzed can be added to a database of call record files with null data values. The first data type can be one or more of the calling or called number, call duration, or base station information. The null data value of the first data type means that, after analyzing the call record file to be analyzed, the data corresponding to the first data type is null. If there are multiple first data types, and any data of the first data type in the call record file to be analyzed is null, the target anomaly cause corresponding to the call record file to be analyzed is determined as the second anomaly cause, and the call record file to be analyzed is added to the database of call record files with null data values.

[0108] It can be understood that the above three data cleaning methods for the call record file to be analyzed can be cleaned in a certain order. For example, the call record file to be analyzed can be cleaned for out-of-network numbers first, then for null values, and finally for compliance. The embodiment of the present invention does not limit the execution order of the data cleaning methods.

[0109] Step 403: If any data of the second data type in the call record file to be analyzed does not satisfy the data format corresponding to the second data type, determine that the target abnormality cause corresponding to the call record file to be analyzed is a third abnormality cause.

[0110] In an embodiment of the present invention, data information of various data types in the call record file to be analyzed has its standard data format, for example, the length of the caller number needs to meet the target number of digits, the call duration is a positive number and cannot be a negative number, etc. In the case that the data of any second data type in the call record file to be analyzed does not meet the data format corresponding to the second data type, it is characterized that the user matching is abnormal due to the non-compliance of the data of the second data type. Therefore, the target abnormality cause corresponding to the call record file to be analyzed can be determined as the second abnormality cause, and the call record file to be analyzed can be added to the data null value abnormal call record database. Among them, the second data type can be one or more of the caller number, call start time, call end time, call duration and base station information. The data format corresponding to the second data type can include one or more of the caller number length meeting the target number of digits, the call start time meeting the preset time format, the call end time meeting the preset time format, the call duration is greater than or equal to 0, and the base station information meets the target length.

[0111] In an embodiment of the present invention, by pre-processing the call record file to be analyzed, situations where the cause of the abnormality can be simply determined are screened in advance. On the premise of accurately determining the target abnormal cause of the call record file to be analyzed, the number of call records to be retrieved and matched in the target vector database is reduced, thereby improving the efficiency of call record abnormality analysis to a certain extent.

[0112] Optionally, the embodiment of the present invention may further include the following steps:

[0113] Step 501: Store the target abnormality cause and the call record vector data in a target vector database corresponding to the target business scenario.

[0114] In an embodiment of the present invention, the target abnormality cause and call record vector data obtained by analyzing the call record file to be analyzed are stored in a target vector database corresponding to the target business scenario to expand the richness of samples in the target vector database.

[0115] In one possible implementation, during the process of processing the call record file to be analyzed by the model, the model can be retrained based on the optimized target vector database according to the target cycle to improve the model's retrieval and matching capabilities, thereby improving the accuracy of call record anomaly analysis.

[0116] Optionally, the embodiment of the present invention may include the following steps:

[0117] Step 601: Acquire a plurality of historical call record data corresponding to at least two business scenarios and call unit data corresponding to each of the historical call record data.

[0118] In the embodiment of the present invention, a plurality of historical call record data corresponding to at least two business scenarios and call unit data corresponding to each historical call record data are obtained.

[0119] Step 602: For any business scenario, perform vector conversion on a plurality of historical call record data corresponding to the business scenario to obtain a plurality of historical vector data.

[0120] In this embodiment of the present invention, historical call record data is divided into business scenarios. Specifically, the business scenarios corresponding to the historical call record data can be determined based on designated fields within the historical call record data. For any business scenario, vector conversion is performed on multiple historical call record data corresponding to the business scenario based on preset labels corresponding to the business scenario, thereby obtaining historical vector data corresponding to each piece of historical call record data. It will be appreciated that the method for vector conversion of historical call record data can be similar to the method for vector conversion of the call record file to be analyzed in step 102, and will not be further described here.

[0121] Step 603: construct a vector database corresponding to the business scenario based on the historical vector data and call unit data of each of the historical call record data corresponding to the business scenario.

[0122] In an embodiment of the present invention, the historical vector data and call unit data of multiple groups of historical call record data corresponding to the business scenario are stored in a vector database, and a suitable indexing algorithm is selected based on the characteristics of the historical vector data and the application scenario. Using the selected indexing algorithm, the historical vector data is constructed into an index structure to obtain a vector database corresponding to the business scenario. Exemplarily, the indexing algorithm organizes the historical vector data into a specific data structure based on the similarity or distance relationship of the historical vector data for subsequent rapid retrieval. Among them, indexing algorithms include KD tree, Annoy, LSH, HNSW, etc.

[0123] In this embodiment of the present invention, by constructing vector databases corresponding to different business scenarios, the vector search process can be accelerated and search efficiency can be improved. Furthermore, by constructing vector databases corresponding to different business scenarios, historical vector data of historical call record data can be obtained based on preset tags corresponding to different business scenarios, forming search modes for different business scenarios and providing targeted search indexes for search and matching of vector data.

[0124] For example, Figure 4 Another specific step flow chart of call record abnormality analysis is shown in FIG. Figure 4As shown, S1: Collect the error bill files output by the pre-collection center, and filter out the bill files to be analyzed based on the error codes corresponding to the abnormal types of bills matched by the users. S2: Convert the non-text bill files to be analyzed, such as the ASN.1 format, into plain text format, and output a unified standard bill format record to unify the data format for subsequent data cleaning and data analysis. S3: Determine the target business scenario corresponding to the bill file to be analyzed based on the specified field. S4: Perform data cleaning on the bill file to be analyzed, including cleaning of inter-network numbers, determining whether the number segment or IMSI segment is for an inter-network user. If so, the bill file to be analyzed is added to the inter-network abnormal bill database; null value cleaning, determining whether the data of the first data type contains null values. If so, the bill file to be analyzed is added to the null value abnormal bill database; compliance cleaning, determining whether the data of the second data type is compliant. If so, the bill file to be analyzed is added to the non-compliant abnormal bill database. If the call record file to be analyzed has not been added to the databases for abnormal call records in different networks, abnormal call records with null values, or abnormal call records with non-compliant characteristics, then S5: The automatic analysis agent service is invoked to invoke the model to search and match the target vector database corresponding to the target business scenario. If the matching value output by the model exceeds the preset threshold, the abnormal cause corresponding to the matching value is determined as the target abnormal cause and added to the analyzed abnormal call record table. If the matching value output by the model is less than or equal to the preset threshold, then S6: Based on the distributed RPA scheduling task, the target abnormal cause corresponding to the call record file to be analyzed is determined according to the target troubleshooting path corresponding to the target business scenario. This reduces the performance and resource overhead of the core customer information management system while improving the efficiency of call record analysis for matching abnormal types, achieving a real-time, efficient, timely, scientific, and rigorous big data model solution. Furthermore, key, difficult, and painful issues can be analyzed item by item, their causes pinpointed, and addressed in real time, effectively improving business response efficiency and reducing time, thereby forming an efficient and comprehensive service system.

[0125] Figure 5 Schematic diagram of a device for analyzing abnormal call records provided by an embodiment of the present invention. Figure 5 As shown, the device may specifically include:

[0126] The first acquisition module 701 is used to obtain the target business scenario corresponding to the call record file to be analyzed;

[0127] A first matching module 702 is configured to perform a search and match based on a target vector database corresponding to the target business scenario and call record vector data corresponding to the call record file to be analyzed, to obtain a cause analysis result;

[0128] A first determining module 703 is configured to determine, when a matching value in the cause analysis result is greater than a preset threshold, a target abnormality cause corresponding to the call record file to be analyzed based on the abnormality cause corresponding to the matching value;

[0129] The second determination module 704 is configured to determine, when the matching value is less than or equal to the preset threshold, a target abnormality cause corresponding to the call record file to be analyzed according to a target troubleshooting path corresponding to the target business scenario.

[0130] Optionally, the device further comprises:

[0131] A third determination module is configured to determine that the target abnormality cause corresponding to the call record file to be analyzed is a first abnormality cause when the different network judgment number segment of the call record file to be analyzed meets the different network judgment condition corresponding to the target business scenario;

[0132] A fourth determining module is configured to determine that the target abnormality cause corresponding to the call record file to be analyzed is a second abnormality cause when any data of the first data type in the call record file to be analyzed is a null value;

[0133] The fifth determination module is used to determine that the target abnormal cause corresponding to the call record file to be analyzed is the third abnormal cause when any data of the second data type in the call record file to be analyzed does not meet the data format corresponding to the second data type.

[0134] Optionally, the second determining module 704 includes:

[0135] A first determination submodule is configured to determine a target troubleshooting path corresponding to the target business scenario based on the target business scenario; the target troubleshooting path is defined by a plurality of business nodes and a business node topology corresponding to each of the business nodes;

[0136] The first calling module is used to call the exception handling node corresponding to the target business scenario, and determine the target exception cause corresponding to the call record file to be analyzed in the business database corresponding to each business node according to the troubleshooting order indicated by the business node topology.

[0137] Optionally, the device further comprises:

[0138] a sixth determining module, configured to determine a target weight value corresponding to the target troubleshooting path based on a weight coefficient corresponding to each of the service nodes in the target troubleshooting path;

[0139] a seventh determining module, configured to determine a processing order corresponding to the call record file to be analyzed based on the target weight value, the number of service nodes in the target troubleshooting path, and the average troubleshooting time corresponding to the target troubleshooting path;

[0140] The first calling module includes:

[0141] The first calling submodule is used to call the exception processing node corresponding to the target business scenario when the processing sequence corresponding to the call record file to be analyzed is reached.

[0142] Optionally, the device further comprises:

[0143] The first storage module is used to store the target abnormality cause and the call record vector data in a target vector database corresponding to the target business scenario.

[0144] Optionally, the device further comprises:

[0145] A second acquisition module is used to obtain a plurality of historical call record data corresponding to at least two business scenarios and call unit data corresponding to each of the historical call record data;

[0146] A first conversion module is configured to perform vector conversion on a plurality of historical call record data corresponding to any business scenario to obtain a plurality of historical vector data;

[0147] The first construction module is used to construct a vector database corresponding to the business scenario based on the historical vector data and the call unit data of each of the historical call record data corresponding to the business scenario.

[0148] The present invention also provides an electronic device, see Figure 6 , including: a processor 801, a memory 802, and a computer program 8021 stored in the memory and capable of running on the processor, and when the processor executes the program, the call record anomaly analysis method of the aforementioned embodiment is implemented.

[0149] The present invention also provides a readable storage medium. When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device can execute the call record anomaly analysis method of the aforementioned embodiment.

[0150] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0151] The algorithm and display provided herein are not inherently related to any particular computer, virtual system or other device. Various general-purpose systems can also be used together with the teachings based on this. According to the above description, it is obvious that the structure required for constructing this type of system. In addition, the present invention is not directed to any specific programming language. It should be understood that various programming languages can be utilized to realize the content of the present invention described herein, and the above description of specific languages is for the purpose of disclosing the best mode of the present invention.

[0152] In the description provided herein, numerous specific details are described. However, it is understood that embodiments of the present invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of this description.

[0153] Similarly, it should be understood that in order to streamline the present invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the claims below, inventive aspects lie in less than all the features of the individual embodiments disclosed above. Accordingly, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of the present invention.

[0154] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and in addition may be divided into multiple submodules or subunits or subcomponents. All features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed herein may be combined in any combination, except that at least some of such features and / or processes or units are mutually exclusive. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0155] The various component embodiments of the present invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It will be appreciated by those skilled in the art that a microprocessor or digital signal processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components of the sorting device according to the present invention. The present invention may also be implemented as an apparatus or device program for performing a portion or all of the methods described herein. Such a program for implementing the present invention may be stored on a computer-readable medium, or may be in the form of one or more signals. Such a signal may be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0156] It should be noted that the above embodiments illustrate rather than limit the invention, and that those skilled in the art may devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between brackets should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention may be implemented by means of hardware comprising several different elements and by means of appropriately programmed computers. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names.

[0157] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0158] It should be noted that all actions of acquiring signals, information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where they are located and with the authorization given by the owner of the corresponding device.

[0159] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

[0160] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A method for analyzing abnormal call records, characterized in that: The method comprises: Obtain the target business scenario corresponding to the call record file to be analyzed; Performing a search and matching based on the target vector database corresponding to the target business scenario and the call record vector data corresponding to the call record file to be analyzed to obtain a cause analysis result; When the matching value in the cause analysis result is greater than a preset threshold, determining the target abnormal cause corresponding to the call record file to be analyzed based on the abnormal cause corresponding to the matching value; When the matching value is less than or equal to the preset threshold, the target abnormality cause corresponding to the call record file to be analyzed is determined according to the target troubleshooting path corresponding to the target business scenario.

2. The method according to claim 1, characterized in that The method further comprises: When the different network judgment number segment of the call record file to be analyzed meets the different network judgment condition corresponding to the target service scenario, determining that the target abnormality cause corresponding to the call record file to be analyzed is the first abnormality cause; When any data of the first data type in the call record file to be analyzed is a null value, determining that the target abnormal cause corresponding to the call record file to be analyzed is a second abnormal cause; When any data of the second data type in the call record file to be analyzed does not satisfy the data format corresponding to the second data type, the target abnormal cause corresponding to the call record file to be analyzed is determined to be a third abnormal cause.

3. The method according to claim 1, characterized in that Determining the target abnormality cause corresponding to the call record file to be analyzed according to the target troubleshooting path corresponding to the target business scenario includes: Based on the target business scenario, determining a target troubleshooting path corresponding to the target business scenario; the target troubleshooting path is defined by multiple business nodes and a business node topology corresponding to each of the business nodes; The exception handling node corresponding to the target business scenario is called, and according to the troubleshooting order indicated by the business node topology, the target exception cause corresponding to the call record file to be analyzed is determined in the business database corresponding to each business node.

4. The method according to claim 3, characterized in that After determining a target troubleshooting path corresponding to the target business scenario based on the target business scenario, the method further includes: Determining a target weight value corresponding to the target troubleshooting path based on a weight coefficient corresponding to each of the service nodes in the target troubleshooting path; Determining a processing order corresponding to the call record files to be analyzed based on the target weight value, the number of service nodes in the target troubleshooting path, and the average troubleshooting time corresponding to the target troubleshooting path; The calling of the exception handling node corresponding to the target business scenario includes: When the processing sequence corresponding to the call record file to be analyzed is reached, the exception processing node corresponding to the target business scenario is called.

5. The method according to claim 1, wherein After determining the target abnormality cause corresponding to the call record file to be analyzed according to the target troubleshooting path corresponding to the target business scenario, the method further includes: The target abnormality cause and the call record vector data are stored correspondingly in a target vector database corresponding to the target business scenario.

6. The method according to claim 1, characterized in that The method further comprises: Acquire multiple historical call record data corresponding to at least two business scenarios and call unit data corresponding to each of the historical call record data; For any business scenario, performing vector conversion on multiple historical call record data corresponding to the business scenario to obtain multiple historical vector data; Based on the historical vector data and call unit data of each of the historical call record data corresponding to the business scenario, a vector database corresponding to the business scenario is constructed.

7. A call record abnormality analysis device, characterized in that: The device comprises: The first acquisition module is used to obtain the target business scenario corresponding to the call record file to be analyzed; A first matching module is configured to perform a search and match based on a target vector database corresponding to the target business scenario and call record vector data corresponding to the call record file to be analyzed, to obtain a cause analysis result; A first determining module is configured to determine, when a matching value in the cause analysis result is greater than a preset threshold, a target abnormal cause corresponding to the call record file to be analyzed based on the abnormal cause corresponding to the matching value; The second determination module is used to determine the target abnormality cause corresponding to the call record file to be analyzed according to the target troubleshooting path corresponding to the target business scenario when the matching value is less than or equal to the preset threshold.

8. The device according to claim 7, characterized in that The device further comprises: A third determination module is configured to determine that the target abnormality cause corresponding to the call record file to be analyzed is a first abnormality cause when the different network judgment number segment of the call record file to be analyzed meets the different network judgment condition corresponding to the target business scenario; A fourth determining module is configured to determine that the target abnormality cause corresponding to the call record file to be analyzed is a second abnormality cause when any data of the first data type in the call record file to be analyzed is a null value; The fifth determination module is used to determine that the target abnormal cause corresponding to the call record file to be analyzed is the third abnormal cause when any data of the second data type in the call record file to be analyzed does not meet the data format corresponding to the second data type.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for analyzing call log anomalies according to any one of claims 1 to 6 is implemented.

10. A readable storage medium, characterized in that: When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is enabled to execute the call record anomaly analysis method described in any one of claims 1-6.

Images