Business request scene judgment method and device, computer equipment, medium and product

Abstract

The invention discloses a service request scene judgment method and device, computer equipment, a medium and a product. The method comprises the steps of obtaining to-be-processed request data input by a user; based on a preset white rule base, judging whether a current request is a normal service request or not according to static content characteristics in the to-be-processed request data; and if not, judging whether the current request is a normal service request or not according to the dynamic behavior characteristics in the to-be-processed request data based on a preset behavior rule base. According to the technical scheme, the normal service requests are quickly filtered out through the preset white rule base, so that the overall judgment efficiency is improved, then the complex requests which are not filtered out through the preset white rule base are further judged and processed from the dynamic behavior characteristics through the preset behavior rule base, and thus the overall judgment accuracy is improved. The two rule libraries supplement each other, the judgment efficiency and accuracy are both considered, and therefore the request scene of a large amount of request data can be efficiently and accurately judged.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of network security and information security technology, and in particular, to a method, device, computer equipment, medium and product for determining a business request scenario. Background Art

[0002] In recent years, network security attacks have become an increasingly serious global problem, and the endless network security incidents have caused huge losses to users and enterprises. Therefore, network security protection has become an increasingly indispensable part. However, in the process of network attack intrusion detection, normal business requests are often misjudged as attack behaviors, which will cause normal business access to be blocked, seriously affecting user experience. In this regard, it is crucial to improve the accuracy and efficiency of business request scenario determination, but the currently commonly used business request scenario determination methods are difficult to meet the requirements of accuracy and efficiency at the same time. Summary of the invention

[0003] Embodiments of the present invention provide a service request scenario determination method, apparatus, computer equipment, medium and product to improve the efficiency and accuracy of service request scenario determination.

[0004] In a first aspect, an embodiment of the present invention provides a method for determining a service request scenario, the method comprising:

[0005] Get the pending request data entered by the user;

[0006] Based on a preset white rule library, determining whether the current request is a normal service request according to static content features in the request data to be processed;

[0007] If not, based on the preset behavior rule library, it is determined whether the current request is a normal business request according to the dynamic behavior characteristics in the request data to be processed.

[0008] Optionally, before determining whether the current request is a normal service request based on the static content features in the request data to be processed based on the preset white rule library, the method further includes:

[0009] Get historical request data;

[0010] Establishing the preset white rule library according to the static content features in the historical request data;

[0011] According to the dynamic behavior characteristics in the historical request data, the preset behavior rule library is established based on the improved C4.5 algorithm.

[0012] Optionally, the establishing the preset behavior rule library based on the improved C4.5 algorithm according to the dynamic behavior characteristics in the historical request data includes:

[0013] Building model input features according to dynamic behavior features in the historical request data;

[0014] Construct the function mapping relationship between model input and model output based on decision tree, random forest and extreme gradient boosting tree respectively;

[0015] Based on the Bayesian optimization algorithm, the number of model input factors and model hyperparameters are optimized to obtain the optimal hyperparameter combination of the model;

[0016] Based on the optimal hyperparameter combination of the model, training is performed according to the model input features and the function mapping relationship to obtain the optimal target mapping function as a dynamic behavior determination rule, and the preset behavior rule library is established according to the dynamic behavior determination rule.

[0017] Optionally, the method further includes:

[0018] Collect the pending request data in real time as the latest training set;

[0019] The algorithm model is retrained according to the latest training set to update the preset behavior rule library.

[0020] Optionally, the method further includes:

[0021] The preset white rule library and the preset behavior rule library are synchronously iterated to the cloud rule library in real time.

[0022] Optionally, the method further includes:

[0023] The preset white rule library and the preset behavior rule library stored in the cloud rule library are screened in real time according to the local application scenario and then synchronized to the local rule library.

[0024] In a second aspect, an embodiment of the present invention further provides a service request scenario determination device, the device comprising:

[0025] A request data acquisition module is used to obtain the request data to be processed input by the user;

[0026] A static content determination module, used to determine whether the current request is a normal service request based on a preset white rule library and static content features in the request data to be processed;

[0027] The dynamic behavior determination module is used to determine whether the current request is a normal business request based on the dynamic behavior characteristics in the request data to be processed based on a preset behavior rule library.

[0028] In a third aspect, an embodiment of the present invention further provides a computer device, the computer device comprising:

[0029] one or more processors;

[0030] A memory for storing one or more programs;

[0031] When the one or more programs are executed by the one or more processors, the one or more processors implement the service request scenario determination method provided by any embodiment of the present invention.

[0032] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the service request scenario determination method provided by any embodiment of the present invention.

[0033] In a fifth aspect, an embodiment of the present invention further provides a computer program product, which includes a computer program. When the program is executed by a processor, the service request scenario determination method provided by any embodiment of the present invention is implemented.

[0034] The embodiment of the present invention provides a method for determining a business request scenario, which first obtains the pending request data input by the user, and then determines whether the current request is a normal business request based on the static content features in the pending request data based on the preset white rule library. If not, then determines whether the current request is a normal business request based on the dynamic behavior features in the pending request data based on the preset behavior rule library. The business request scenario determination method provided by the embodiment of the present invention first analyzes and matches the static content features using the preset white rule library, which can quickly filter out normal business requests, thereby improving the overall determination efficiency, and then uses the preset behavior rule library to further determine and process the complex requests that are not filtered out by the preset white rule library based on the dynamic behavior features, thereby improving the overall determination accuracy. Through the complementary nature of the two rule libraries, both determination efficiency and accuracy are taken into account, so that efficient and accurate determination of request scenarios for a large amount of request data can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 A flowchart of a method for determining a service request scenario provided in Embodiment 1 of the present invention;

[0036] Figure 2 This is an architecture diagram of a method for determining a service request scenario provided in Embodiment 1 of the present invention;

[0037] Figure 3 A schematic diagram of the structure of a service request scenario determination device provided in Embodiment 2 of the present invention;

[0038] Figure 4 This is a schematic diagram of the structure of a computer device provided in Embodiment 3 of the present invention. DETAILED DESCRIPTION

[0039] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0040] It should be mentioned before discussing the exemplary embodiments in more detail that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe the steps as sequential processes, many of the steps therein can be implemented in parallel, concurrently or simultaneously. In addition, the order of the steps can be rearranged. The process can be terminated when its operation is completed, but can also have additional steps not included in the accompanying drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0041] Embodiment 1

[0042] Figure 1 Flow chart of the business request scenario determination method provided in the first embodiment of the present invention. This embodiment can be applied to the situation where the security of business requests provided by users is determined in the fields of enterprise network security protection, cloud computing security, Web application protection, financial system security, etc. The method can be executed by the business request scenario determination device provided in the embodiment of the present invention, which can be implemented by hardware and / or software and can generally be integrated into a computer device. Figure 1 As shown, the specific steps include:

[0043] S11. Obtain the request data to be processed input by the user.

[0044] S12. Based on a preset white rule library, determine whether the current request is a normal service request according to static content features in the request data to be processed.

[0045] S13: If not, based on a preset behavior rule library, determine whether the current request is a normal business request according to dynamic behavior characteristics in the request data to be processed.

[0046] Specifically, the business request scenario determination method provided in this embodiment can be a business request scenario determination method based on a rule model. A rule model is a model that makes decisions, judges or processes information based on clearly defined rules and logic. This model uses a predefined rule set to process and analyze the input data and output the data analysis results. Each rule in the rule set usually consists of a condition part (IF) and an action part (THEN). The condition part defines the rule trigger condition, which can be one or more logical expressions, and the action part defines the operation to be performed when the condition is met. Then, the rule model can be used to analyze and determine whether the business request conforms to the expected behavior to determine the legitimacy, validity and security of the request, and after the determination is completed, the operation corresponding to the determination result can be performed. Exemplarily, determine whether a user login request comes from a legitimate user, or determine whether a transaction request conforms to business rules, etc. The corresponding IF-THEN representation example is as follows: IF the number of user login failures exceeds 5 THEN lock the account; IF the request comes from an untrusted IP address THEN deny access, etc.

[0047] For the business request scenario determination method based on the rule model, two rule bases with high coverage and high accuracy are predefined, namely the preset white rule base and the preset behavior rule base. Among them, the preset white rule base is used to store business request scenario determination rules based on static content features, and can specifically store static content features belonging to normal business requests. It is the primary rule base of the entire rule model and directly affects the determination processing efficiency of the model. The preset behavior rule base is used to store business request scenario determination rules based on dynamic behavior features. It is the core rule base of the entire rule model and directly affects the determination processing accuracy of the model. The rules in the rule base can be arranged in descending order according to priority, and the priority can be set based on accuracy, coverage, total description length or the order in which the rules are generated. At the same time, the rules in the rule base also need to meet mutual exclusivity and exhaustiveness. Mutual exclusivity means that each input request data is covered by at most one rule, and no two rules in the rule set are triggered at the same time. Exhaustiveness means that for any combination of attribute values ​​of each input request data, there is a rule to cover it, ensuring that each request data is covered by at least one rule. Among them, static content features may include request content, request data format, request parameters, request authentication information, request authorization credentials, etc., and dynamic behavior features may include access frequency, operation sequence, time interval, geographic location consistency, device identification consistency, resource access status, operation log judgment, etc.

[0048] When the pending request data input by the user is obtained, the pending request data can be parsed to obtain the corresponding static content features and dynamic behavior features. Then, the static content features are matched and analyzed based on the preset white rule library. If it is determined to be a normal business request, the judgment is completed and the judgment result is obtained. By performing efficient rule matching and judgment based on the preset white rule library, normal business requests can be quickly filtered out. If it cannot be determined as a normal business request based on the preset white rule library, the dynamic behavior features are further analyzed and judged based on the preset behavior rule library, and the judgment result can be obtained, that is, it is determined to be a normal business request or an abnormal attack behavior. For example, multiple intranet IPs trigger the same rules for the same business URL in the intranet, which can be judged as a normal business request from the behavior. After obtaining the judgment result of the business request scenario, the corresponding operation can be performed based on the rule model.

[0049] On the basis of the above technical solution, optionally, before determining whether the current request is a normal business request based on the static content features in the request data to be processed based on the preset white rule base, it also includes: obtaining historical request data; establishing the preset white rule base based on the static content features in the historical request data; establishing the preset behavior rule base based on the improved C4.5 algorithm according to the dynamic behavior features in the historical request data. Specifically, before being put into actual scenarios for determination, a large amount of historical request data can be collected in advance as the original data set of the business request scenario, and the required preset white rule base and preset behavior rule base can be constructed based on the original data set. Specifically, it can be constructed based on expert experience knowledge. First, the original data set is studied and analyzed, and the static content features and dynamic behavior features for business scenario determination are extracted therefrom. Then, a preset white rule base is established based on the static content features, and a preset behavior rule base is established based on the dynamic behavior features. By establishing a rule base based on the characteristics of static content and dynamic behavior, both determination efficiency and accuracy are taken into account.

[0050] Based on expert experience and knowledge, the significant features of normal business requests and abnormal attack behaviors in static content and dynamic behavior can be extracted through in-depth and comprehensive analysis, including: For the static content of normal business requests, for example, from the perspective of legality, normal business requests are usually legal and meet the system's expected input and operations, such as user login, data query, file upload, etc. From the perspective of format specification, the data format and parameters of normal business requests are usually standardized and meet the requirements of API or system. From the perspective of authentication and authorization, normal business requests usually contain valid authentication information and authorization credentials to ensure the identity and authority of the requester; For the static content of abnormal attack behaviors, for example, from the perspective of legality, abnormal attack behaviors may contain malicious content such as malicious code, SQL injection, cross-site scripting (XSS), etc. From the perspective of format specification, the data format of abnormal attack behaviors may be abnormal, such as containing overlong strings, special characters or parameters that do not meet the specifications. From the perspective of authentication and authorization, abnormal attack behaviors may forge authentication information or use stolen credentials to perform unauthorized operations. In addition, abnormal attack behaviors may also try to hide their true intentions through obfuscation technology, encrypted data, etc. Evasion of detection; Dynamic behavior of normal business requests. For example, from the perspective of user behavior patterns, normal business requests usually conform to the normal behavior patterns of users, such as access frequency, operation sequence, time interval, etc. From the perspective of geographic location and equipment, normal business requests usually come from the geographical locations and equipment commonly used by users, and are consistent. From the perspective of resource access, the amount and frequency of access to system resources by normal business requests are usually within a reasonable range and will not consume resources excessively. From the perspective of operation logs, normal business requests are displayed as normal operations in system logs, without abnormal or suspicious behavior; Dynamic behavior of abnormal attack behavior. For example, from the perspective of user behavior patterns, the behavior patterns of abnormal attack behaviors are usually abnormal, such as a large number of requests in a short period of time, operations in abnormal time periods, etc. From the perspective of geographic location and equipment, abnormal attack behaviors may come from suspicious IP addresses or devices, such as anonymous proxies, TOR networks, etc. From the perspective of resource access, abnormal attack behaviors may attempt to consume system resources excessively, such as DDoS attacks, brute force cracking, etc. From the perspective of operation logs, abnormal attack behaviors may be displayed as abnormal operations in system logs, such as frequent login failures, access to restricted resources, etc. It can be seen that normal business requests and abnormal attack behaviors have obvious characteristics and differences in content and behavior. Normal business requests are usually legal, standardized and consistent with normal user behavior patterns, while abnormal attack behaviors may contain malicious content, abnormal formats, forged identities and abnormal behavior patterns.

[0051] Static content features can be easily judged directly through matching and comparison. After extracting the static content features from the historical request data, rules can be directly formulated based on expert experience knowledge to build a preset white rule base. The reasoning process of establishing a preset white rule base based on expert experience knowledge is clear and easy to interpret. However, dynamic behavior features are difficult to judge directly through matching and comparison. After extracting the dynamic behavior features from the historical request data, rules can be formulated based on the improved C4.5 algorithm to build a preset behavior rule base. The preset behavior rule base does not need to rely on experience knowledge and can handle new situations or changes that have not been seen. Among them, the C4.5 algorithm is similar to the business request scenario judgment process and works better in extracting judgment rules.

[0052] Further optionally, the preset behavior rule library is established based on the improved C4.5 algorithm according to the dynamic behavior characteristics in the historical request data, including: constructing model input characteristics according to the dynamic behavior characteristics in the historical request data; constructing a function mapping relationship between model input and model output based on decision trees, random forests and extreme gradient boosting trees respectively; optimizing the number of model input factors and model hyperparameters based on the Bayesian optimization algorithm to obtain the optimal hyperparameter combination of the model; based on the optimal hyperparameter combination of the model, training is performed according to the model input characteristics and the function mapping relationship to obtain the optimal target mapping function as the dynamic behavior judgment rule, and establishing the preset behavior rule library according to the dynamic behavior judgment rule.

[0053] Further optionally, the method also includes: collecting the pending request data in real time as the latest training set; retraining the algorithm model according to the latest training set to update the preset behavior rule library. Specifically, after the actual scenario is put into judgment, the latest pending request data can also be collected in real time as the latest training set, so as to update the preset behavior rule library through retraining, so as to continuously update and expand the rules according to the characteristics of the new request data in real time to adapt to different business environments. It is also possible to feedback the misjudgment results in real time according to the actual situation after each judgment is completed, and adjust the algorithm penalty coefficient in real time based on the misjudgment results, so as to dynamically update and optimize the preset behavior rule library to adapt to complex and changeable business request data.

[0054] Optionally, the method further includes: synchronizing and iterating the preset white rule base and the preset behavior rule base to the cloud rule base in real time. Specifically, the dynamic synchronization iteration of the cloud rule base can be achieved after the initial construction of the two rule bases and after the subsequent update of the rule bases. The architecture diagram of the business request scenario determination method based on the rule model is shown in FIG. Figure 2As shown, a user interface can be provided to interact with the user through a visual interface. The user can input the pending request data through the interface, view the final business request judgment result through the interface, and modify the business request scenario judgment rules in the two rule bases, etc. The working storage can store the currently input pending request data and the judgment result output by the judgment engine, record the data information used and generated during the judgment process, etc. The judgment engine is responsible for executing the judgment process. It can first obtain the pending request data from the working storage, then process and analyze the data features, and match them according to the business request scenario judgment rules in the two rule bases in turn, and finally output the business request scenario judgment result. The preset white rule base and the preset behavior rule base can be stored in the cloud through the cloud rule base. Any network point connected to the cloud rule base can synchronize the preset white rule base and the preset behavior rule base, and can also feedback misjudgment information, etc. The modification of the two rule bases usually does not actively affect other connected networks, and the maintenance cost is low.

[0055] Further optionally, the method also includes: screening the preset white rule library and the preset behavior rule library stored in the cloud rule library in real time according to the local application scenario and synchronizing them to the local rule library to adapt to local needs, thereby improving the flexibility of the determination method.

[0056] Taking a specific application example as an example, in the cloud control + edge computing environment application scenario, some edge nodes have low resource configuration, which is not enough to support the deployment of enterprise-level firewall software, and even difficult to access WAF equipment. This brings considerable challenges to the edge node API protection. By applying this method to the edge node, a large number of normal business requests can be quickly filtered, and multiple abnormal requests can be identified, which effectively improves the filtering efficiency and judgment accuracy of the business request scenario. In the enterprise network environment application scenario, this method is applied in the internal network environment of the enterprise to achieve real-time filtering of normal business requests and interception of abnormal requests, effectively identify and block multiple abnormal requests, and protect the security of the internal network data of the enterprise.

[0057] The technical solution provided by the embodiment of the present invention first obtains the pending request data input by the user, and then determines whether the current request is a normal business request based on the static content features in the pending request data based on the preset white rule library. If not, then it determines whether the current request is a normal business request based on the dynamic behavior features in the pending request data based on the preset behavior rule library. First, by using the preset white rule library to analyze and match the static content features, normal business requests can be quickly filtered out, thereby improving the overall judgment efficiency. Then, by using the preset behavior rule library for complex requests that are not filtered out by the preset white rule library, further judgment processing is performed based on the dynamic behavior features, thereby improving the overall judgment accuracy. Through the complementary nature of the two rule libraries, both judgment efficiency and accuracy are taken into account, so that efficient and accurate judgment of request scenarios with a large amount of request data can be achieved.

[0058] Embodiment 2

[0059] Figure 3 This is a schematic diagram of the structure of the service request scenario determination device provided in the second embodiment of the present invention. The device can be implemented by hardware and / or software, and can generally be integrated into a computer device to execute the service request scenario determination method provided in any embodiment of the present invention. Figure 3 As shown, the device comprises:

[0060] The request data acquisition module 31 is used to acquire the request data to be processed input by the user;

[0061] A static content determination module 32, configured to determine whether the current request is a normal service request based on a preset white rule library and static content features in the request data to be processed;

[0062] The dynamic behavior determination module 33 is used to determine whether the current request is a normal business request based on the dynamic behavior characteristics in the request data to be processed based on a preset behavior rule library.

[0063] The technical solution provided by the embodiment of the present invention first obtains the pending request data input by the user, and then determines whether the current request is a normal business request based on the static content features in the pending request data based on the preset white rule library. If not, then it determines whether the current request is a normal business request based on the dynamic behavior features in the pending request data based on the preset behavior rule library. First, by using the preset white rule library to analyze and match the static content features, normal business requests can be quickly filtered out, thereby improving the overall judgment efficiency. Then, by using the preset behavior rule library for complex requests that are not filtered out by the preset white rule library, further judgment processing is performed based on the dynamic behavior features, thereby improving the overall judgment accuracy. Through the complementary nature of the two rule libraries, both judgment efficiency and accuracy are taken into account, so that efficient and accurate judgment of request scenarios with a large amount of request data can be achieved.

[0064] On the basis of the above technical solution, optionally, the service request scenario determination device further includes:

[0065] A historical data acquisition module, used for acquiring historical request data before determining whether the current request is a normal business request based on the static content features in the request data to be processed based on the preset white rule library;

[0066] A white rule base establishing module, used to establish the preset white rule base according to the static content features in the historical request data;

[0067] The behavior rule library establishment module is used to establish the preset behavior rule library based on the improved C4.5 algorithm according to the dynamic behavior characteristics in the historical request data.

[0068] On the basis of the above technical solution, optionally, the behavior rule library establishment module is specifically used for:

[0069] Building model input features according to dynamic behavior features in the historical request data;

[0070] Construct the function mapping relationship between model input and model output based on decision tree, random forest and extreme gradient boosting tree respectively;

[0071] Based on the Bayesian optimization algorithm, the number of model input factors and model hyperparameters are optimized to obtain the optimal hyperparameter combination of the model;

[0072] Based on the optimal hyperparameter combination of the model, training is performed according to the model input features and the function mapping relationship to obtain the optimal target mapping function as a dynamic behavior determination rule, and the preset behavior rule library is established according to the dynamic behavior determination rule.

[0073] On the basis of the above technical solution, optionally, the service request scenario determination device further includes:

[0074] A latest training set acquisition module, used for collecting the pending request data in real time as the latest training set;

[0075] The behavior rule library updating module is used to retrain the algorithm model according to the latest training set to update the preset behavior rule library.

[0076] On the basis of the above technical solution, optionally, the service request scenario determination device further includes:

[0077] The cloud rule base synchronization module is used to synchronize and iterate the preset white rule base and the preset behavior rule base to the cloud rule base in real time.

[0078] On the basis of the above technical solution, optionally, the service request scenario determination device further includes:

[0079] The local rule base synchronization module is used to screen the preset white rule base and the preset behavior rule base stored in the cloud rule base in real time according to the local application scenario and then synchronize them to the local rule base.

[0080] The service request scenario determination device provided in the embodiment of the present invention can execute the service request scenario determination method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0081] It is worth noting that in the embodiment of the above-mentioned business request scenario determination device, the various units and modules included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention.

[0082] Embodiment 3

[0083] Figure 4 The schematic diagram of the structure of the computer device provided for the third embodiment of the present invention shows a block diagram of an exemplary computer device suitable for implementing the implementation mode of the present invention. Figure 4 The computer device shown is only an example and should not limit the functions and scope of use of the embodiments of the present invention. Figure 4 As shown, the computer device includes a processor 41, a memory 42, an input device 43 and an output device 44; the number of processors 41 in the computer device can be one or more. Figure 4 Taking a processor 41 as an example, the processor 41, memory 42, input device 43 and output device 44 in the computer device can be connected through a bus or other means. Figure 4 The example of connecting through bus is taken in the following.

[0084] The memory 42, as a computer-readable storage medium, can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the business request scenario determination method in the embodiment of the present invention (for example, the request data acquisition module 31, the static content determination module 32 and the dynamic behavior determination module 33 in the business request scenario determination device). The processor 41 executes various functional applications and data processing of the computer device by running the software programs, instructions and modules stored in the memory 42, that is, realizing the above-mentioned business request scenario determination method.

[0085] The memory 42 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 42 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 42 may further include a memory remotely arranged relative to the processor 41, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0086] The input device 43 may be used to obtain the request data to be processed input by the user, and to generate key signal input related to the user setting and function control of the computer device, etc. The output device 44 may include a display screen, which may be used to display the determination result, etc. to the user.

[0087] Embodiment 4

[0088] Embodiment 4 of the present invention further provides a storage medium including computer executable instructions, which, when executed by a computer processor, is used to execute a service request scenario determination method, the method comprising:

[0089] Get the pending request data entered by the user;

[0090] Based on a preset white rule library, determining whether the current request is a normal service request according to static content features in the request data to be processed;

[0091] If not, based on the preset behavior rule library, it is determined whether the current request is a normal business request according to the dynamic behavior characteristics in the request data to be processed.

[0092] The storage medium may be any of various types of memory devices or storage devices. The term "storage medium" is intended to include: installation media, such as CD-ROM, floppy disk or tape device; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (such as hard disk or optical storage); registers or other similar types of memory elements, etc. The storage medium may also include other types of memory or combinations thereof. In addition, the storage medium may be located in the computer system in which the program is executed, or may be located in a different second computer system, which is connected to the computer system via a network (such as the Internet). The second computer system may provide program instructions to the computer for execution. The term "storage medium" may include two or more storage media that may reside in different locations (e.g., in different computer systems connected via a network). The storage medium may store program instructions (e.g., embodied as a computer program) that may be executed by one or more processors.

[0093] Of course, the computer executable instructions of a storage medium including computer executable instructions provided in an embodiment of the present invention are not limited to the operations of the method described above, and can also execute related operations in the service request scenario determination method provided in any embodiment of the present invention.

[0094] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0095] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0096] Through the above description of the implementation methods, the technicians in the relevant field can clearly understand that the present invention can be implemented by means of software and necessary general hardware, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk or optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0097] Embodiment 5

[0098] Embodiment 5 of the present invention also provides a computer program product, which includes a computer program (also referred to as code, instruction), which can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it is used to execute the business request scenario determination method provided in any of the above embodiments, and has the corresponding beneficial effects of the execution method.

[0099] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for determining a business request scenario, characterized in that: include: Get the pending request data entered by the user; Based on a preset white rule library, determining whether the current request is a normal service request according to static content features in the request data to be processed; If not, based on the preset behavior rule library, it is determined whether the current request is a normal business request according to the dynamic behavior characteristics in the request data to be processed.

2. The method for determining a service request scenario according to claim 1, characterized in that: Before determining whether the current request is a normal service request based on the static content features in the request data to be processed based on the preset white rule library, the method further includes: Get historical request data; Establishing the preset white rule library according to the static content features in the historical request data; According to the dynamic behavior characteristics in the historical request data, the preset behavior rule library is established based on the improved C4.5 algorithm.

3. The method for determining a service request scenario according to claim 2, wherein: The step of establishing the preset behavior rule library based on the improved C4.5 algorithm according to the dynamic behavior characteristics in the historical request data includes: Building model input features according to dynamic behavior features in the historical request data; Construct the function mapping relationship between model input and model output based on decision tree, random forest and extreme gradient boosting tree respectively; Based on the Bayesian optimization algorithm, the number of model input factors and model hyperparameters are optimized to obtain the optimal hyperparameter combination of the model; Based on the optimal hyperparameter combination of the model, training is performed according to the model input features and the function mapping relationship to obtain the optimal target mapping function as a dynamic behavior determination rule, and the preset behavior rule library is established according to the dynamic behavior determination rule.

4. The method for determining a service request scenario according to claim 3, wherein: The method further comprises: Collect the pending request data in real time as the latest training set; The algorithm model is retrained according to the latest training set to update the preset behavior rule library.

5. The method for determining a service request scenario according to any one of claims 2 to 4, characterized in that: The method further comprises: The preset white rule library and the preset behavior rule library are synchronously iterated to the cloud rule library in real time.

6. The method for determining a service request scenario according to claim 5, characterized in that: The method further comprises: The preset white rule library and the preset behavior rule library stored in the cloud rule library are screened in real time according to the local application scenario and then synchronized to the local rule library.

7. A service request scenario determination device, characterized in that: include: A request data acquisition module is used to obtain the request data to be processed input by the user; A static content determination module, used to determine whether the current request is a normal service request based on a preset white rule library and static content features in the request data to be processed; The dynamic behavior determination module is used to determine whether the current request is a normal business request based on the dynamic behavior characteristics in the request data to be processed based on a preset behavior rule library.

8. A computer device, characterized in that: include: one or more processors; A memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the service request scenario determination method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the service request scenario determination method as described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the service request scenario determination method as described in any one of claims 1 to 6.

Images