Risk processing method, device, readable medium and program product

Abstract

The invention provides a risk processing method and device, electronic equipment, a computer readable medium and a computer program product. The method comprises the following steps: in response to a detected target behavior, obtaining a context feature of the target behavior; determining whether risk processing is triggered or not based on the cooling state of the target behavior; if the risk processing is triggered, evaluating the risk based on the context features and executing the corresponding risk processing; and dynamically setting a cooling period corresponding to the target behavior according to an evaluation result. According to the method, context features such as frequency-related information, time-related information and historical hit records of behaviors are introduced, and a cooling control mechanism is combined to ensure that the same object does not repeatedly trigger judgment in a cooling period after strategy hit, so that the situation of repeated disposal is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to a method and device for risk processing, an electronic device, a computer readable medium and a computer program product. BACKGROUND

[0002] With the increasing complexity of content platform management, user behavior control and system frequency control scenarios, traditional risk policy systems gradually expose many limitations when coping with new demands. At present, the traditional risk policy system generally relies on methods such as fixed threshold-based sliding window counting frequency judgment and static list screening to execute related policies. For example, judgment is made based on features such as user ID or source IP and access frequency. However, this single judgment method cannot accurately identify the risk differences of behaviors in different contexts, resulting in frequent misjudgment and missed judgment. For example, high active behavior of normal users may be mistakenly intercepted, and some abnormal behaviors may evade inspection through dispersed distribution.

[0003] In high-frequency behavior scenarios, for example, the frequency of AI recognition in some businesses can reach the minute level. If there is a lack of effective cooling control mechanism, the system may repeatedly calculate and trigger the policy for the same object multiple times. This not only wastes a lot of computing resources, but also may cause redundancy of disposal actions, seriously affecting the running efficiency and resource utilization efficiency of the system. SUMMARY

[0004] Aspects of the present application provide a method, device, electronic device, computer readable medium and computer program product for risk processing.

[0005] In an aspect of the present application, a method for risk processing is provided, wherein the method comprises: in response to detecting a target behavior, obtaining context features of the target behavior; determining whether to trigger risk processing based on a cooling state of the target behavior; if risk processing is triggered, evaluating risk based on the context features and performing corresponding risk processing; dynamically setting a cooling period corresponding to the target behavior according to the evaluation result.

[0006] In an aspect of the present application, a risk processing system is provided, comprising: an event collection end for collecting generated target behavior events; a policy service end for executing the method of the embodiments of the present application; and an execution end for executing corresponding risk disposal according to instructions from the policy service end.

[0007] In an aspect of the present application, a device for risk processing is provided, wherein the device comprises: The feature acquisition module is configured to acquire a context feature of the target behavior in response to detecting the target behavior. The cooling judgment module is configured to determine whether to trigger risk processing based on a cooling state of the target behavior. The risk assessment module is configured to, if the risk processing is triggered, assess a risk based on the context feature and perform corresponding risk processing. The cooling update module is configured to dynamically set a cooling period corresponding to the target behavior according to an assessment result.

[0008] In another aspect of the present application, an electronic device includes at least one processor and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of the embodiments of the present application.

[0009] In another aspect of the present application, a computer readable storage medium is provided, which stores computer program instructions executable by a processor to implement the method of the embodiments of the present application.

[0010] In another aspect of the present application, a computer program product is provided, which includes a computer program executable by a processor to implement the method of the embodiments of the present application.

[0011] In the scheme provided by the embodiments of the present application, by introducing the context features such as frequency-related information, time-related information and historical hit records of the behavior, the traditional static threshold judgment is replaced, the risk degree of the target behavior can be more comprehensively assessed, the accuracy of risk judgment is improved, various risk behaviors can be more effectively managed and disposed, and the multiple dimensions corresponding to the context features are supported as independent judgment conditions or joint combination conditions, the flexible construction of the hit risk strategy logic is realized; based on the behavior count in a specific time period, combined with the cooling control mechanism, it is ensured that the same object will not trigger the judgment repeatedly in the cooling period after the strategy hits, so as to reduce the repeated disposal and the system overhead; by splitting the strategy execution into three independent modules, each module supports independent configuration, log output and linkage feedback, forming a clear execution link, which is conducive to realizing unified management and reuse optimization in the platform, and the execution logic and parameters of each module can be flexibly configured through the configuration file or the management interface, and through the asynchronous linkage mechanism, each module can be independently run without blocking, thereby improving the overall performance and maintainability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort based on these drawings.

[0013] Other features, objects, and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments thereof, read in conjunction with the accompanying drawings: Figure 1 A flowchart of a method for risk processing according to an embodiment of the present application is shown; Figure 2 A flowchart of a processing flow of an exemplary policy engine system according to an embodiment of the present application is shown; Figure 3 A structural diagram of an apparatus for risk processing according to an embodiment of the present application is shown; Figure 4 A structural diagram of a risk processing system according to an embodiment of the present application is shown; Figure 5 A structural diagram of an apparatus suitable for implementing the solutions in the embodiments of the present application is shown.

[0014] The same or similar reference signs in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0015] In order to make the objects, technical solutions and advantages of the embodiments of the present application more clear, the following will combine the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort fall within the scope of the present application.

[0016] In a typical configuration of the present application, the devices of the terminal and the service network each include one or more processors (CPU), input / output interfaces, network interfaces and memories.

[0017] The memory can include a non-permanent memory in a computer readable medium, random access memory (RAM) and / or non-volatile memory such as read only memory (ROM) or flash memory (flash RAM). The memory is an example of the computer readable medium.

[0018] Computer-readable media includes permanent and non-permanent, removable and non-removable media, which can be implemented by any method or technology to store information. Information can be computer program instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage device, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0019] Figure 1 A flowchart of a method for risk processing according to an embodiment of the present application is shown. The method includes at least steps S101, S102, S103 and S104.

[0020] In actual scenarios, the execution subject of the method can be a network device, or also an application running on a network device, including but not limited to network hosts, single network servers, multiple network server sets or cloud computing-based computer sets, etc. for implementing part of the processing functions when setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, where cloud computing is a kind of distributed computing, composed of a virtual computer set of a loose-coupled computer group.

[0021] Referring to Figure 1 In step S101, in response to detecting a target behavior, the context features of the target behavior are acquired.

[0022] The target behavior includes various risk behaviors that need to be processed. For example, for a video live streaming website, risk behaviors can include modifying the live streaming room title multiple times, using the same device to register multiple times, frequently accessing or publishing risk content, etc. For example, for an e-commerce website, risk behaviors can include frequently changing the delivery address, performing a large number of refund operations in a short period of time, using multiple accounts to place batch orders, etc.

[0023] The context feature is a multi-dimensional information group composed of object-related information, frequency-related information, time-related information, hit record information, etc. The context feature is used for context filtering, i.e., according to the time period of the behavior, the behavior frequency, the historical risk record, etc. The behavior context factors are dynamically evaluated to determine whether the target behavior meets the conditions for triggering subsequent risk processing strategies. The risk processing strategies include risk processing measures for various risk behaviors. These measures may include but are not limited to warning prompts, limited function use, account restrictions, or, if necessary, linkage with manual review processes, etc. Each measure aims to effectively address specific types of risk behaviors while maintaining minimal interference with normal user behavior.

[0024] According to one embodiment, the context feature includes but is not limited to: 1) Object-related information; the object-related information includes various information related to the user who makes the target behavior, such as user identification, user account, user level or reputation score in the platform, etc.

[0025] 2) Frequency-related information; the frequency-related information includes various information that can indicate the frequency of occurrence of the target behavior. Optionally, the number of times the target behavior occurs within a predetermined period of time and the distribution day information, which refers to the number of days the target behavior occurs within the predetermined period of time.

[0026] 3) Time-related information: the time-related information includes various information related to the occurrence time of the target behavior, such as the target behavior event timestamp. Optionally, the time-related information may also include further analysis of the occurrence time of the target behavior, such as determining whether the behavior occurs in a specific high-risk time period, such as the last 3 days, the last week, or other custom time windows.

[0027] 4) Hit record information: the hit record information includes relevant historical records of past risk processing of corresponding users due to the same or similar behavior. "Hit" refers to a behavior or a type of behavior that is determined to be a risk behavior that requires intervention based on risk processing strategies. The hit record information includes but is not limited to hit time, user identification information, risk behavior name or type, risk level, risk disposal measures taken, and cooling period, etc.

[0028] Optionally, the method records each hit behavior event in detail in a global log system, including but not limited to the specific time of the hit, the user ID involved, the risk level evaluated, the disposal action taken, and the subsequent cooling period, etc. At the same time, a cooling mark with an expiration time is generated for the relevant object in the cooling register, which will exist until it naturally expires or is manually intervened to be removed.

[0029] The historical hit record is accumulated in the frequency statistics, and the historical weight is provided for the risk level assessment, so that the system can more accurately assess the risk level of the object.

[0030] Optionally, in order to improve the query efficiency, the system can optionally store the hit record and the cooling mark through the cache (such as Redis or Memcached), so that the retrieval of the historical hit record can be completed in constant time.

[0031] According to an embodiment, step S101 includes step S1011 and step S1012.

[0032] In step S1011, event stream data from multiple data sources is obtained.

[0033] The event stream data includes but is not limited to behavioral objects (such as user ID), behavior types, behavior event occurrence time, and other meta information.

[0034] The multiple data sources include but are not limited to content evaluation results, risk control alarms, user behavior logs, and user feedback signals. These data sources may have the same data structure or different structures.

[0035] In order to realize efficient data collection, the system continuously receives and integrates event streams from these data sources through message queues (such as Kafka) or real-time log stream technology. These event stream data usually contain behavioral objects (such as user ID), behavior types, and specific behavior event occurrence times.

[0036] The embodiments of the present application receive event stream data through multiple data channels, including but not limited to: Message queue channel: Use message queue technology (such as Kafka) to realize efficient data transmission and buffering. Kafka, as a high-performance distributed message system, can handle high-throughput data and support persistent storage and flexible consumption mode of data; Real-time log stream channel: Capture and transmit log data through real-time log stream technology (such as Flume or Logstash). These tools can collect user behavior logs in real time and transmit them to the data processing system.

[0037] Risk control alarm channel: Obtain alarm information directly from the risk control system. These alarm information usually contains key risk indicators and decision basis.

[0038] User feedback channel: Receive user feedback through a special interface. These data can come from the feedback mechanism of the user interface or the customer service channel.

[0039] Through the above multi-channel data access mode, the system can continuously receive and integrate event stream data from different data sources.

[0040] It should be noted that the user-related data involved in the embodiments of the present application are obtained with the consent or permission of the relevant object. In addition, the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0041] In step S1012, context analysis is performed based on the event stream data to obtain frequency-related information, time-related information and hit record information of the target behavior as context features.

[0042] Specifically, context analysis is performed on the event stream data to analyze the target object information to which the event belongs. Then, the frequency-related information, time-related information and hit record information are obtained. Among them, the frequency-related information is given by sliding count, which is obtained by real-time summarizing the daily number of the object for the target behavior in the past T days and accumulating the cumulative value; the time-related information is recorded by bitmap, which marks the specific date of the target behavior and counts the number of days in the same window; the hit record information is quickly screened by Bloom filter, and if it hits, the corresponding hit time and other record information are obtained. Finally, these information are spliced in fixed field order to form context features.

[0043] According to an embodiment, in step S1012, the cumulative number of times of the target behavior of the target object in the time period corresponding to the preset sliding time window is obtained. For example, the cumulative number of times of a certain type of behavior of the target object in the past T days can be calculated based on formula (1) as follows: (1) Wherein, represents the behavior object (such as user ID, live room ID), represents the behavior type, represents the number of times of triggering the behavior on the i-th day, and T represents the sliding time window, which is in units of days or hours.

[0044] According to an embodiment, in step S1012, it is determined how many days the target behavior has occurred in the time period corresponding to the preset sliding time window. For example, the number of days in which a certain type of behavior has occurred in the past T days can be obtained based on formula (2) as follows: (2) Wherein, represents the number of days or times of behavior in the window, , , ​and T have the same meaning as in equation (1).

[0045] According to an embodiment, the way of extracting the context features includes but is not limited to: 1) Streaming computing framework completes fields: using Apache Flink or Spark Structured Streaming, when events arrive, fields are pulled and completed by asynchronous queries. For example, taking user identification as the key, the number of cumulative behaviors of the user in the past seven days is queried, the event timestamp is compared with the sliding window boundary to confirm whether the event is within the past seven days, and the user policy hit record is read. After the fields are completed, the context feature record is encapsulated and delivered to the downstream.

[0046] 2) Lightweight UDF parses and fills in features: lightweight user-defined functions (UDFs) are embedded in the message queue consumption end to directly parse JSON / Avro messages. For example, when the scale of the scene is small or the delay requirement is high, the function looks up the user identification through local cache, and calls the user center interface to complete the data when the cache is missing, and assembles the frequency, time and historical hit record three features at one time.

[0047] Continue to refer to Figure 1 It is explained that in step S102, it is determined whether to trigger risk processing based on the cooling state of the target behavior.

[0048] The cooling state is used to indicate whether the target behavior is in a preset cooling period, so as to avoid repeated processing of the same behavior in a short time, thereby reducing the waste of system resources and preventing misjudgment.

[0049] According to an embodiment, in step S102, it is determined whether it is in the preset cooling period of the target behavior. If it is in the cooling period, the event count of the target behavior is updated and the operation is terminated. If it is not in the cooling period, the risk processing procedure for the target behavior is triggered.

[0050] The cooling period is a period for cooling control. In the embodiment of the application, the cooling period is set to cool control a behavior within a certain time. Once the behavior triggers the corresponding strategy, it will be locked within a certain period of time (for example, several hours or several days), and during this period, the same strategy will not be triggered again. This approach helps to reduce the occurrence of high-frequency false positives and saves system resources.

[0051] The determination method of the cooling state includes: 1) The cooling state is determined by comparing the size of the time difference and the cooling period, and the time difference is the difference between the time when the target behavior occurs and the time when the last risk processing strategy is hit; Specifically, the difference between the time when the target behavior occurs and the time when the last risk handling strategy is hit is calculated, and compared with the preset cooling period. Optionally, it is checked whether the difference between the current time and the last strategy hit time is greater than or equal to the length of the cooling period, and if this condition is met, the system determines that the target behavior is not in the cooling period; if not, the target behavior is still in the cooling period.

[0052] For example, it is determined whether the target behavior is in the preset cooling period by judging whether the expression shown below is met: (3) wherein represents the cooling period, and the unit can be day or hour, represents the current time, represents the last strategy hit time. If the expression is met, it is determined that the cooling period is not met, otherwise the cooling period is met.

[0053] 2) Determine the cooling state based on the cooling mark of the target behavior; Specifically, when the event of the target behavior arrives, the global cooling register is queried with the identifier of the behavior as the primary key. If there is an unexpired cooling mark in the register, the system determines that the target behavior is still in the preset cooling period, and at this time only the count is updated and the current event is discarded quickly; if the cooling mark does not exist or has expired, it is determined that the target behavior is not in the cooling period.

[0054] Optionally, the cooling mark is a record, the key of which is composed of "object unique identifier + strategy ID", and the value includes "cooling expiration timestamp + cooling type flag". Among them, the cooling type can include global cooling (affecting the execution of all risk strategies of the object), single strategy cooling (only affecting the execution of the current risk strategy). After the disposal action is executed, the hit record and the cooling mark are written into the log and the cache together to support the strategy feedback loop. The cooling period length calculated is converted into an absolute expiration time and written into the key, and the remaining survival period of the key is the constraint of the cooling period of the object. After the survival period ends, the key is automatically deleted, and the object is out of the cooling state; if it needs to be released in advance, a special interface can be called to delete the key; if the same object triggers the strategy again within the cooling period, the survival period can be renewed or reset to extend or refresh the cooling period.

[0055] In step S103, if the risk handling is triggered, the risk is evaluated based on the context features and the corresponding risk handling is performed.

[0056] The evaluation result obtained by evaluating the risk includes the determination result of whether the target behavior is a risk behavior that needs to be intervened and the risk level of the risk behavior. The risk level is used to indicate the severity of the target behavior.

[0057] For example, the risk level includes three levels of "low risk", "medium risk" and "high risk", which correspond to different risk handling operations such as "light prompt", "general warning" and "serious treatment" respectively.

[0058] According to an embodiment, the step S103 includes a step S1031 and a step S1032.

[0059] In step S1031, the risk level corresponding to the target behavior is evaluated according to the context features.

[0060] Optionally, based on a preset risk judgment standard, the corresponding risk level is evaluated according to one or more information in the context features. The risk judgment standard includes a preset behavior condition and a corresponding risk level. For example, in an e-commerce scenario, for the dimension of transaction frequency, the preset behavior condition can be "transaction times more than 5 times within 24 hours", and the corresponding risk level is "medium risk". For the dimension of login location, the preset behavior condition can be "login IP address is not in the same city as the last login IP address", and the corresponding risk level is "high risk".

[0061] Embodiments of the present application support composite logical expressions to construct behavior conditions for each risk level, to achieve more complex and flexible risk evaluation rules. For example, the behavior condition can be set as "behavior times ≥ 10 times in the last X days and the distribution days of the behavior ≥ 5 days". This composite logical expression can more accurately capture abnormal behavior patterns. In this way, the risk level of user behavior can be evaluated comprehensively according to the context features of multiple dimensions and the risk judgment standard constructed by the composite logical expression, so as to effectively identify potential risks and take corresponding measures.

[0062] Optionally, the risk level is evaluated by quantitatively scoring the context features based on preset risk scoring criteria. The risk scoring criteria include static parameters such as frequency threshold table, time sensitivity coefficient, and historical risk handling weight. For example, the frequency threshold table sets thresholds according to the frequency of user behavior. If the user logs in more than 5 times within 24 hours, a certain risk base score will be given; if more than 10 times, the risk score will be further increased. The time sensitivity coefficient considers the time distribution of behavior. If the user's behavior is concentrated in a short time, such as within 1 hour, a higher risk coefficient will be given; if the behavior is distributed over a longer period of time, such as within 7 days, a lower risk coefficient will be given. The historical risk handling weight is weighted according to the risk record of the user's historical behavior. If the user has had high-risk behavior before and has been handled, a higher risk weight will be given in the current behavior risk assessment. Then, each context feature is scored by these static parameters, and the scores are added up to get a comprehensive risk score. Finally, the comprehensive risk score is mapped to the final risk level by a piecewise function. For example, 0-5 points correspond to low risk, 6-10 points correspond to medium risk, and 11 points and above correspond to high risk.

[0063] Those skilled in the art should be familiar with that the risk level and the risk level corresponding to the target behavior can be set based on various ways, and those skilled in the art can select appropriate ways based on actual conditions.

[0064] In step S1032, one or more risk handling operations matching the risk level are performed based on the pre-stored risk handling policy.

[0065] The risk handling policy includes information indicating one or more risk handling operations corresponding to different risk levels.

[0066] The risk handling operation includes various types of restriction handling measures. In the scenario of a video live streaming platform, the risk handling operation includes but is not limited to account ban, flow limiting, pop-up prompt, recommendation sinking, content shielding, warning notification, and function use restriction, etc. These handling measures can be flexibly combined according to the risk level and specific scenarios to ensure the safe and stable operation of the platform.

[0067] For example, in the context of a video live streaming platform, if a user modifies the title up to 5 times within 72 hours, it triggers risk handling policy A, causing the system to execute a pop-up warning. If a device registers behavior that triggers policy 2 times within 7 days, it triggers risk handling policy B, causing the device to be temporarily banned and setting a 3-day cooling period to limit repeated triggering of the risk handling policy. If a user accesses risk content multiple times within the last 7 days and has a history of risk handling records, it triggers risk handling policy C, causing the system to send a reminder to the operations team.

[0068] For example, in the context of an e-commerce platform, if a seller modifies the title of a product up to 5 times within 72 hours, it triggers risk handling policy X, causing the system to execute a pop-up warning, reminding the seller to comply with platform rules and avoid frequently modifying titles to mislead consumers. If a user frequently places orders but cancels them multiple times within 7 days, it triggers risk handling policy Y, causing the system to set a 3-day cooling period for the user's account, during which time the order placement function is limited. By setting a cooling period, repeated triggering of the risk handling policy is limited, thus limiting the order placement function. If a user accesses the platform's privacy data (such as bulk export of user data) multiple times within the last 7 days and has a history of risk handling records, it may trigger risk handling policy Z, causing the system to send a reminder to the operations team for further investigation of whether there is a data leakage risk or other risk behavior.

[0069] For example, in the context of an Internet of Things (IoT) device, if a smart door lock device is attempted multiple times with incorrect passwords within 7 days, it triggers policy M, causing the system to send a warning notification to the user and suggest checking for abnormal login attempts. If a smart camera device is remotely controlled multiple times within the last 7 days, it triggers policy N, which may cause the system to implement cloud control frequency limits for the device, such as limiting the number of remote controls within 24 hours, or adjusting the frequency of the device's remote control function through firmware updates to prevent the device from being maliciously manipulated.

[0070] In other scenarios, for example, in the context of interface calls, if a user frequently calls a specific interface within a short period of time, it triggers a risk handling policy that causes the system to set an interface frequency limit for the user's account, limiting the frequency of interface calls within a certain period of time to prevent abuse of the interface. In the context of message pushing, if a user frequently triggers push events, it triggers a risk handling policy that causes the system to set a push frequency control for the user's account, limiting the frequency of push messages received within a certain period of time to avoid disturbing the user with too many messages. These measures effectively reduce the probability of risk behavior through cooling mechanisms and frequency limits, while ensuring the stable operation of the system and user experience.

[0071] According to one embodiment, the method uses a trained machine learning model to output a corresponding risk assessment result based on the context features, the risk assessment result including a determination of whether the target behavior is a risky behavior requiring intervention and a risk level of the risky behavior.

[0072] Among them, the model receives the context features including user level, historical operation trajectory, timestamp, etc. as the input feature vector, and outputs the risk assessment result accordingly.

[0073] Optionally, the model adopts a lightweight structure design, and candidate schemes include XGBoost, logistic regression or deep shallow network, etc. These models can be deployed as PMML or ONNX file format to support hot loading and gray rollback.

[0074] Among them, in the training phase of the model, the historical policy hit log is used as the positive sample, and the miss log is used as the negative sample. The feature vector of the training data includes multiple dimensions such as user level, behavior frequency in the recent certain days, timestamp distribution, device fingerprint, historical risk processing times, and relationship network weight. In the inference phase, the real-time extracted context features are converted into the same vector format as in the training phase and input into the model, and the model outputs the risk judgment (0 represents non-risk behavior, and 1 represents risky behavior) and risk level.

[0075] The model in this embodiment can provide real-time risk assessment for the policy engine, helping the system to identify and respond to potential risky behaviors with higher accuracy and efficiency, while minimizing the interference to normal user behaviors.

[0076] In step S104, the cooling period corresponding to the target behavior is dynamically set according to the evaluation result, to start a new round of cooling period.

[0077] Among them, if it is the first time to perform risk processing on the target behavior, the corresponding cooling period is determined according to the evaluation result, and if it is not the first time to perform risk processing, the new cooling period is determined according to the evaluation result and the cooling period corresponding to the target behavior is updated accordingly.

[0078] According to one embodiment, in step S104, the cooling period corresponding to the target behavior is dynamically set based on the risk level obtained by evaluation.

[0079] Specifically, the corresponding relationship between the risk level and the cooling period length of the pre-stored risky behavior is obtained, and the cooling period length matching the risk level obtained by evaluation is determined.

[0080] For example, assume that the risk level includes four levels: low, medium, high, and extremely high. Each level corresponds to a cooling period length: no cooling for low risk, one minute for medium risk, five minutes for high risk, and fifteen minutes for extremely high risk.

[0081] According to an embodiment, the cooling period corresponding to the target behavior is determined or updated based on the evaluated risk level and in combination with key information in the context features. Step S104 of this embodiment further includes steps S1041-S1043.

[0082] In step S1041, the cooling period corresponding to the target behavior is determined based on the evaluated risk level as a baseline length.

[0083] In step S1042, one or more key information is selected from the context features, which is used to adjust the cooling period length. For example, information in the user dimension and the behavior event dimension is selected from the context features as key information, including how many times the user has performed the same action in the past predetermined period, the credit level information of the user himself, the risk score of the device and IP used at the time of the behavior event, and the time period when the behavior event occurred.

[0084] In step S1043, the baseline length is dynamically adjusted based on one or more key information to obtain the cooling period corresponding to the target behavior.

[0085] Specifically, based on one or more key information, the baseline length is dynamically adjusted according to a preset length adjustment rule to obtain the cooling period corresponding to the target behavior.

[0086] For example, if the user has recently operated frequently and has been intercepted multiple times, or the device and IP are at high risk, the system will increase the baseline length; on the contrary, if the user is highly reliable and the device environment is clean, the cooling period length will be decreased.

[0087] Optionally, in order to control extreme values, the system sets upper and lower limits for the cooling period. For example, the cooling period is not longer than one hour, and the shortest can be zero. If the user has an abnormally high frequency of operation in a short period of time, even if the calculated cooling period is very short, it will be forced to increase to half a minute to prevent the interface from being maliciously brushed.

[0088] According to one embodiment, a machine learning model is used to predict the probability of re-triggering risk processing within a future predetermined time period based on context features, and the cooling period is set accordingly based on the probability. Specifically, a machine learning model is first used to predict the probability of re-triggering risk processing within a future time period in real time based on context features (user historical trigger times, credit level, device / IP risk score, behavior time period, etc.); then, according to the correspondence between the preset probability value range and the cooling period length, the cooling period length matching the predicted probability is determined, thereby dynamically generating the cooling period. Optionally, the cooling period is protected by a preset upper and lower limit, and if the model output is an extreme value, it is forced to be truncated or raised, thereby preventing false positives and avoiding being bypassed.

[0089] The model can use a variety of model structures such as a logistic regression model, a random forest model, a gradient boosting decision tree model (GBDT), or a deep learning model (such as a deep neural network, DNN). Those skilled in the art can select a suitable model for risk probability prediction based on actual business needs and data characteristics, and dynamically set the cooling period based on the prediction results.

[0090] According to one embodiment, the method further comprises step S105.

[0091] In step S105, a corresponding cooling mark is set based on the dynamically determined or updated cooling period of the target behavior.

[0092] The setting of the cooling mark ensures that the system can effectively limit and manage user behavior according to the latest cooling period length, thereby ensuring the stability and security of the system.

[0093] According to the method of the embodiments of the present application, by introducing context features such as frequency-related information, time-related information, and historical hit records, instead of traditional static threshold judgment, the risk level of the target behavior can be more comprehensively evaluated, the accuracy of risk judgment is improved, which helps to more effectively manage and dispose of various risk behaviors, and supports multiple dimensions corresponding to the context features as independent judgment conditions or joint combination conditions, realizing flexible construction of hit risk strategy logic; based on "behavior count within a specific time period", combined with the cooling control mechanism, it is ensured that the same object will not trigger the judgment repeatedly within the cooling period after the strategy is hit, thereby reducing the repeated disposal and reducing the system overhead; by splitting the strategy execution into three independent modules, each module supports independent configuration, log output, and linkage feedback, forming a clear execution link, which is conducive to unified management and reuse optimization in the platform, and the execution logic and parameters of each module can be flexibly configured through a configuration file or a management interface, and through an asynchronous linkage mechanism, each module can run independently and not be blocked, thereby improving the overall performance and maintainability of the system.

[0094] The processing flow of the exemplary policy engine system will be described below with reference to the accompanying drawings. Figure 2 The flow of the present example is executed by a policy engine system that processes risky behavior based on received events. The policy engine system is composed of a series of policy execution modules such as judgment, counting, filtering, and disposal.

[0095] The flow of the present example is executed by a policy engine system that processes risky behavior based on received events. The policy engine system is composed of a series of policy execution modules such as judgment, counting, filtering, and disposal.

[0096] Referring to Figure 2 , the processing flow of the policy engine system includes: After receiving an event containing a user ID, event type, and timestamp, the policy engine first aggregates the number of similar behaviors in the last several days, historical labels, and risk processing records of the user into context features; Next, check if the user is on the whitelist: if on the whitelist, the entire event is directly skipped to the policy logic and no further processing is performed; if not on the whitelist, continue to check if the user is currently in the cooling-off period; If already in the cooling-off period, the policy engine will not trigger any disposal action, but only update the count in the sliding window for subsequent statistical use; if not in the cooling-off period, enter the sliding window counting link, and accumulate the number of behaviors of the user according to the pre-set time granularity to obtain the total number N; Compare N with two thresholds X1 and X2 (X2> X1), when N is greater than or equal to X2, it is determined to be serious, and the Level 2 level policy action is executed; when N is between X1 and X2, it is determined to be general, and the Level 1 level policy action is executed; if N is less than X1, no disposal is made; Specifically, the present example determines the risk level according to the cumulative behavior number N, and the risk level determination function is represented as follows: (4) Wherein, and represent the lower and upper bounds of the segmented interval, respectively, The output value represents different risk levels.

[0097] After the policy action is executed, the system records a detailed hit log and sets a cooling-off marker, so that subsequent events are exempted from repeated calculation and judgment during the cooling-off period until the cooling-off period ends.

[0098] Figure 3 A structural schematic diagram of an apparatus for risk processing according to an embodiment of the present application is shown. The apparatus includes a feature acquisition module 101, a cooling processing module 102, a risk assessment module 103, and a cooling update module 104.

[0099] The feature acquisition module 101 acquires the context features of the target behavior in response to detecting the target behavior.

[0100] The target behavior includes various risk behaviors that need to be processed. For example, for a video live streaming website, risk behaviors can include modifying the live streaming room title multiple times, using the same device to register multiple times, frequently accessing or publishing risky content, etc. For example, for an e-commerce website, risk behaviors can include frequently changing the delivery address, performing a large number of refund operations in a short period of time, using multiple accounts to place batch orders, etc.

[0101] The context features are a multi-dimensional information set composed of object-related information, frequency-related information, time-related information, and hit record information. The context features are used for context filtering, i.e., dynamically evaluating whether the target behavior meets the conditions for triggering subsequent risk processing strategies according to the time period of the behavior, the behavior frequency, the historical risk record, and other behavior context factors. The risk processing strategies include risk processing measures for various risk behaviors. These measures can include but are not limited to warning prompts, restrictions on the use of functions, restrictions on accounts, or, if necessary, linkage with the manual review process, etc. Each measure aims to effectively deal with a specific type of risk behavior while maintaining minimal interference with normal user behavior.

[0102] According to one embodiment, the context features include but are not limited to: 1) Object-related information; the object-related information includes various information related to the user who made the target behavior, such as user identification, user account, user level or reputation score in the platform, etc.

[0103] 2) Frequency-related information; the frequency-related information includes various information that can indicate the frequency of occurrence of the target behavior. Optionally, the number of times the target behavior occurs within a predetermined period of time and the distribution day information, which refers to the number of days within the predetermined period of time that the target behavior occurs.

[0104] 3) Time-related information: the time-related information includes various information related to the occurrence time of the target behavior, such as the target behavior event timestamp. Optionally, the time-related information can also include further analysis of the occurrence time of the target behavior, such as determining whether the behavior occurs in a specific high-risk time period, such as the last 3 days, the last week, or other custom time windows.

[0105] 4) Hit record information: This hit record information includes the relevant historical records of past risk handling of corresponding users due to the same or similar behaviors. Among them, "hit" refers to a behavior or a type of behavior that is determined to be a risk behavior that needs to be intervened based on the risk handling strategy. The hit record information includes but is not limited to hit time, user identification information, risk behavior name or type, risk level, risk disposal measures taken, and cooling period, etc.

[0106] Optionally, the device records in detail each hit behavior event in the global log system, and these records include but are not limited to the specific time of the hit, the user ID involved, the risk level assessed, the disposal action taken, and the subsequent cooling period, etc. key information. At the same time, a cooling mark with an expiration time is generated for the relevant object in the cooling register, which will exist until it naturally expires or is manually intervened to be removed.

[0107] Among them, the historical hit record will accumulate the number of hits each time in the frequency statistics, providing historical weight for risk level assessment, so that the system can more accurately assess the risk level of the object.

[0108] Optionally, in order to improve query efficiency, the system can optionally store hit records and cooling marks through cache (such as Redis or Memcached), so that the retrieval of historical hit records can be completed in constant time.

[0109] According to an embodiment, the feature acquisition module 101 includes an event data acquisition module and an event data parsing module.

[0110] The event data acquisition module acquires event stream data from multiple data sources.

[0111] Among them, the event stream data includes but is not limited to behavior objects (such as user ID), behavior types, behavior event occurrence time, etc. meta information.

[0112] Among them, the multiple data sources include but are not limited to data generated by content evaluation results, risk control alarms, user behavior logs, user reporting signals, etc. These data sources may have the same data structure, or may have different structures.

[0113] In order to realize efficient data collection, the system continuously receives and integrates event streams from these data sources through message queues (such as Kafka) or real-time log stream technology. These event stream data usually contain behavior objects (such as user ID), behavior types, and basic meta information such as the specific time of behavior event occurrence.

[0114] Among them, the event stream data is received through multiple data channels by the embodiments of the application, including but not limited to a message queue channel, a real-time log stream channel, a risk control alarm channel and a user feedback channel.

[0115] It should be noted that the user-related data involved in the embodiments of the application is obtained with the consent or permission of the relevant object. In addition, the collection, use and processing of the relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0116] The event data analysis module performs context analysis based on the event stream data to obtain frequency-related information, time-related information and hit record information of the target behavior as context features.

[0117] Specifically, the event data analysis module performs context analysis on the event stream data to analyze the target object information to which the event belongs. Then, the frequency-related information, the time-related information and the hit record information are obtained. Among them, the frequency-related information is given by sliding counting, which is obtained by real-time summarizing the daily number of the target behavior of the object in the past T days and accumulating the cumulative value; the time-related information is recorded by bitmap, which marks the specific date of the target behavior and counts the number of days in the same window; the hit record information is quickly screened by the Bloom filter, and if it hits, the corresponding hit time and other record information are obtained. Finally, these information are spliced in fixed field order to form context features.

[0118] According to one embodiment, the event data analysis module obtains the cumulative number of target behaviors of the target object in the time period corresponding to the preset sliding time window. For example, the cumulative number of a certain type of behavior of the target object in the past T days can be calculated based on formula (1).

[0119] According to one embodiment, the event data analysis module determines how many days the target behavior occurs in the time period corresponding to the preset sliding time window. For example, based on formula (2), it is obtained that how many days a certain type of behavior occurs in the past T days.

[0120] Continue to refer to Figure 3 It is explained that the cooling processing module 102 determines whether to trigger risk processing based on the cooling state of the target behavior.

[0121] Among them, the cooling state is used to indicate whether the target behavior is in a preset cooling period, so as to avoid repeated processing of the same behavior in a short time, thereby reducing the waste of system resources and preventing misjudgment.

[0122] According to one embodiment, the cooling processing module 102 judges whether it is in a cooling period of a target behavior preset, and if it is in the cooling period, the event count of the target behavior is updated and the operation is terminated, and if it is not in the cooling period, a risk processing procedure for the target behavior is triggered to be executed.

[0123] The cooling period is a period for cooling control. In the embodiment of the application, the cooling period is set to cool control a certain behavior within a certain time. Once the behavior triggers a corresponding strategy, it will be locked for a certain period (for example, several hours or several days), and the same strategy will not be triggered again during this period. This approach helps to reduce the occurrence of high-frequency false positives and save system resources.

[0124] The determination of the cooling state includes: 1) determining the cooling state by comparing the time difference and the cooling period, wherein the time difference is the difference between the time of the target behavior and the time of the last hit of the risk processing strategy; Specifically, the difference between the time of the target behavior and the time of the last hit of the risk processing strategy is calculated, and compared with the preset cooling period. Optionally, it is checked whether the difference between the current time and the last strategy hit time is greater than or equal to the length of the cooling period. If this condition is met, the system determines that the target behavior is not in the cooling period; if not, the target behavior is still in the cooling period.

[0125] 2) determining the cooling state based on the cooling mark of the target behavior; Specifically, when the event of the target behavior arrives, the global cooling register is queried with the identifier of the behavior as the primary key. If there is an unexpired cooling mark in the register, the system determines that the target behavior is still in the preset cooling period, and at this time only the count is updated and the current event is discarded quickly; if the cooling mark does not exist or has expired, it is determined that the target behavior is not in the cooling period.

[0126] If the risk processing is triggered, the risk assessment module 103 assesses the risk based on the context features and executes corresponding risk processing.

[0127] The assessment result obtained by assessing the risk includes a determination result of whether the target behavior is a risk behavior that needs to be intervened and a risk level of the risk behavior. The risk level is used to indicate the severity of the target behavior.

[0128] According to one embodiment, the risk assessment module 103 includes a level assessment module and a strategy execution module.

[0129] The level assessment module assesses the risk level corresponding to the target behavior according to the context features.

[0130] Optionally, based on a preset risk judgment standard, the risk level is evaluated according to one or more pieces of information in the context features. The risk judgment standard includes preset behavior conditions and corresponding risk levels. For example, in an e-commerce scenario, for the dimension of transaction frequency, the preset behavior condition can be “transaction frequency more than 5 times within 24 hours”, and the corresponding risk level is “medium risk”. For the dimension of login location, the preset behavior condition can be “login IP address not in the same city as the last login IP address”, and the corresponding risk level is “high risk”.

[0131] The embodiments of the present application support composite logical expressions to construct the behavior conditions of each risk level, so as to realize more complex and flexible risk evaluation rules. For example, the behavior condition can be set as “behavior frequency ≥ 10 times in the last X days and the distribution of the behavior ≥ 5 days”. This composite logical expression can more accurately capture abnormal behavior patterns. In this way, the risk level of user behavior can be comprehensively evaluated according to the context features of multiple dimensions and the risk judgment standard constructed by the composite logical expression, so as to effectively identify potential risks and take corresponding measures.

[0132] Optionally, the level evaluation module evaluates the risk level by quantitatively scoring the context features based on a preset risk scoring standard. The risk scoring standard includes static parameters such as frequency threshold table, time sensitivity coefficient and historical risk handling weight. For example, the frequency threshold table sets a threshold according to the frequency of user behavior. If the user logs in more than 5 times within 24 hours, a certain risk base score will be given; if more than 10 times, the risk score will be further increased. The time sensitivity coefficient considers the time distribution of the behavior. If the user's behavior is concentrated in a short time, such as within 1 hour, a higher risk coefficient will be given; if the behavior is distributed in a longer period of time, such as within 7 days, a lower risk coefficient will be given. The historical risk handling weight is weighted according to the risk records of the user's historical behavior. If the user has had high-risk behavior before and has been handled, a higher risk weight will be given in the current risk evaluation of the behavior. Then, the scores of each context feature are scored by these static parameters, and the scores are added up to get a comprehensive risk score. Finally, the comprehensive risk score is mapped to the final risk level by a piecewise function. For example, 0-5 points correspond to low risk, 6-10 points correspond to medium risk, and 11 points and above correspond to high risk.

[0133] Those skilled in the art should be familiar with that the risk level and the risk level corresponding to the target behavior can be set based on various ways, and those skilled in the art can select appropriate ways based on actual conditions.

[0134] The policy execution module executes one or more risk handling operations matching the risk level based on a pre-stored risk handling policy.

[0135] The risk handling policy includes information indicating one or more risk handling operations corresponding to different risk levels.

[0136] The risk handling operations include various types of restriction handling measures. In the context of a video live streaming platform, the risk handling operations include, but are not limited to, account banning, flow limiting, pop-up prompting, recommendation sinking, content shielding, warning notification, and function usage restriction, etc. These handling measures can be flexibly combined according to the risk level and specific scenarios to ensure the safe and stable operation of the platform.

[0137] According to an embodiment, the method uses a trained machine learning model to output a corresponding risk assessment result based on the context features, the risk assessment result including a determination result of whether the target behavior is a risk behavior requiring intervention and a risk level of the risk behavior.

[0138] The model receives context features including user level, historical operation trajectory, timestamp, etc. as an input feature vector and outputs a risk assessment result accordingly.

[0139] Optionally, the model adopts a lightweight structure design, and candidate solutions include XGBoost, logistic regression, or deep shallow network, etc. These models can be deployed as PMML or ONNX file formats to support hot loading and gray rollback.

[0140] During the training phase of the model, historical policy hit logs are used as positive samples and miss logs are used as negative samples. The feature vector of the training data includes multiple dimensions such as user level, behavior frequency in the recent certain number of days, timestamp distribution, device fingerprint, historical risk handling times, and relationship network weight. During the inference phase, the real-time extracted context features are converted into the same vector format as during training and input into the model, which then outputs a risk judgment (0 represents a non-risk behavior and 1 represents a risk behavior) and a risk level.

[0141] The cooling update module 104 dynamically sets a cooling period corresponding to the target behavior according to the evaluation result to start a new round of cooling period.

[0142] If it is the first time to handle the target behavior, the cooling update module 104 determines the corresponding cooling period according to the evaluation result. If it is not the first time to handle the risk, a new cooling period is determined according to the evaluation result and the cooling period corresponding to the target behavior is updated accordingly.

[0143] According to an embodiment, the cooling updating module 104 dynamically sets the cooling period corresponding to the target behavior based on the evaluated risk level.

[0144] Specifically, the corresponding relationship between the risk level and the cooling period length of the pre-stored risk behavior is obtained, and the cooling period length matching the evaluated risk level is determined.

[0145] For example, it is assumed that the risk level includes four levels: low, medium, high, and extremely high. Each level corresponds to a cooling period length: no cooling for low risk, one minute for medium risk, five minutes for high risk, and fifteen minutes for extremely high risk.

[0146] According to an embodiment, the cooling updating module 104 determines or updates the cooling period corresponding to the target behavior based on the evaluated risk level and in combination with key information in the context features. The cooling updating module 104 performs the following operations: determining the cooling period corresponding to the target behavior based on the evaluated risk level as a reference length; filtering one or more key information from the context features, which is used to adjust the cooling period length. For example, the information of the user dimension and the behavior event dimension is filtered from the context features, including how many times the user has performed the same action in the past predetermined period, the credit level information of the user himself, the risk score of the device and IP used at the time of the behavior event, and the time period when the behavior event occurs, etc. as key information; dynamically adjusting the reference length based on one or more key information to obtain the cooling period corresponding to the target behavior; specifically, based on one or more key information, the reference length is dynamically adjusted according to the preset length adjustment rule to obtain the cooling period corresponding to the target behavior.

[0147] For example, if the user has recently operated frequently and has been intercepted multiple times, or the device and IP are at high risk, the system will increase the base length; on the contrary, if the user is highly reliable and the device environment is clean, the cooling period length will be decreased.

[0148] Optionally, in order to control extreme values, the system sets upper and lower limits for the cooling period. For example, the cooling period is not longer than one hour, and the shortest can be zero. If the user has an abnormally high frequency of operation in a short period of time, even if the calculated cooling period is very short, it will be forced to increase to half a minute to prevent the interface from being maliciously brushed.

[0149] According to an embodiment, the cooling update module 104 adopts a machine learning model to predict the probability of re-triggering the execution of risk processing in a future predetermined time period based on the context features, and sets the cooling period accordingly based on the probability. Specifically, the machine learning model is first used to comprehensively predict the probability of re-triggering the execution of risk processing in a future time period in real time based on the context features (user historical trigger times, credit level, device / IP risk score, behavior time period, etc.); then, according to the correspondence between the preset probability value range and the cooling period length, the cooling period length matching the predicted probability is determined, so as to dynamically generate the cooling period. Optionally, the cooling period is protected by a preset upper and lower limit, and if the model output is an extreme value, it is forced to be truncated or raised, so as to prevent misjudgment and avoid being bypassed.

[0150] The model can adopt a variety of model structures such as a logistic regression model, a random forest model, a gradient boosting decision tree model (GBDT), or a deep learning model (such as a deep neural network, DNN). A person skilled in the art can select a suitable model for risk probability prediction according to actual business needs and data characteristics, and dynamically set the cooling period based on the prediction result.

[0151] According to an embodiment, the device further comprises a label setting module.

[0152] The label setting module sets a corresponding cooling label based on the dynamically determined or updated cooling period of the target behavior.

[0153] The setting of the cooling label ensures that the system can effectively limit and manage user behavior according to the latest cooling period length, thereby ensuring the stability and security of the system.

[0154] The device according to the embodiments of the present application can more comprehensively evaluate the risk degree of the target behavior by introducing the frequency-related information, time-related information, and historical hit records of the behavior as context features, instead of the traditional static threshold judgment, thereby improving the accuracy of risk judgment, helping to more effectively manage and dispose of various risk behaviors, and supporting the use of multiple dimensions corresponding to the context features as independent judgment conditions or joint combination conditions to flexibly construct the hit risk strategy logic; based on the behavior count in a specific time period, combined with the cooling control mechanism, the cooling period of the same object after the strategy hits is ensured not to trigger the judgment repeatedly, thereby reducing the repeated disposal and reducing the system overhead; by splitting the strategy execution into three independent modules, each module supports independent configuration, log output, and linkage feedback, forming a clear execution link, which is conducive to unified management and reuse optimization in the platform, and the execution logic and parameters of each module can be flexibly configured through a configuration file or a management interface, and through an asynchronous linkage mechanism, each module can run independently without blocking, thereby improving the overall performance and maintainability of the system.

[0155] Figure 4 A structural schematic diagram of a risk processing system according to an embodiment of the present application is shown. Referring to Figure 4 , the risk processing system includes an event collection end 401, a policy service end 402, and an execution end 403.

[0156] The event collection end 401 is configured to collect a generated target behavior event.

[0157] The policy service end 402 is configured to execute the method of the present application, in response to detecting a target behavior, acquire a context feature of the target behavior, determine whether to trigger risk processing based on a cooling state of the target behavior, if risk processing is triggered, evaluate risk based on the context feature, and dynamically set a cooling period corresponding to the target behavior according to an evaluation result.

[0158] The execution end 403 is configured to execute corresponding risk disposal according to an instruction from the policy service end.

[0159] Based on the same inventive concept, an electronic device is also provided in the embodiments of the present application, the method corresponding to the electronic device can be the method for performing risk processing in the foregoing embodiments, and the problem solving principle thereof is similar to the method. The electronic device provided in the embodiments of the present application includes at least one processor, and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method and / or technical solution of the foregoing embodiments of the present application.

[0160] The electronic device can be a user device, or a device integrated by a user device and a network device through a network, or also can be an application program running on the above device, the user device includes but is not limited to computers, mobile phones, tablet computers, smart watches, wristbands, and various terminal devices, and the network device includes but is not limited to network hosts, single network servers, multiple network server sets, or computer sets based on cloud computing, which can be used to implement part of the processing function when setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, wherein cloud computing is a kind of distributed computing, and a virtual computer composed of a group of loosely coupled computer sets.

[0161] Figure 5The structure of a device suitable for implementing the method and / or technical solution in the embodiments of the present application is shown. The device 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 1202 or loaded from a storage portion 1208 into a random access memory (RAM) 1203. In the RAM 1203, various programs and data required for system operation are also stored. The CPU 1201, the ROM 1202, and the RAM 1203 are connected to each other through a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0162] The following components are connected to the I / O interface 1205: an input portion 1206 including a keyboard, a mouse, a touch screen, a microphone, an infrared sensor, and the like; an output portion 1207 including a cathode ray tube (CRT), a liquid crystal display (LCD), an LED display, an OLED display, and the like, and a speaker, and the like; a storage portion 1208 including one or more computer readable media such as a hard disk, an optical disk, a magnetic disk, a semiconductor memory, and the like; and a communication portion 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, and the like. The communication portion 1209 performs communication processing via a network such as the Internet.

[0163] In particular, the method and / or embodiments in the embodiments of the present application can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product including a computer program carried on a computer readable medium, the computer program containing program codes for executing the method shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 1201, the above-mentioned functions defined in the method of the present application are performed.

[0164] Another embodiment of the present application also provides a computer readable storage medium having stored thereon computer program instructions, which can be executed by a processor to implement the method and / or technical solution of any one or more embodiments of the present application.

[0165] In particular embodiments, any appropriate combination of one or more computer readable media can be utilized. The computer readable media can be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium can be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0166] A computer readable signal medium can include a propagated data signal with computer readable program code embodied therein, for use by or in connection with an instruction execution system, apparatus, or device. The computer readable program code can be transmitted using any appropriate medium, including but not limited to wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0167] Computer readable program code embodied on a computer readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0168] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In an embodiment of the application, the remote computer can be a server or another desktop computer.

[0169] The flow diagrams and block diagrams in the drawings are presented to illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments disclosed. In this regard, each block in the flow diagrams and block diagrams can represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or combinations of special purpose hardware and

[0170] Those skilled in the art can clearly understand that, for the convenience and brevity, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0171] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the device embodiments described above are merely schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or page components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0172] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0173] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of hardware plus software functional unit.

[0174] The integrated unit implemented in the form of software function unit can be stored in a computer readable storage medium. The software function unit is stored in a storage medium, and includes a plurality of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute part of steps of the method described in various embodiments of the present application. The storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various storage medium capable of storing program codes.

[0175] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

[0176] In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. The plurality of units or devices stated in the apparatus can also be implemented by one unit or device through software or hardware. The words "first", "second" and the like are used to indicate names, and do not mean any specific order.

Claims

1. A method for risk processing, wherein, The method comprises: in response to detecting a target behavior, obtaining context features of the target behavior; determining whether to trigger risk processing based on the cooling state of the target behavior; if risk processing is triggered, evaluating the risk based on the context features and performing corresponding risk processing; dynamically setting the cooling period corresponding to the target behavior according to the evaluation result.

2. The method of claim 1, wherein, The determination method of the cooling state comprises: determining the cooling state by comparing the time difference value and the size of the cooling period, the time difference value being the difference between the time of the target behavior and the time of the last hit risk processing strategy; determining the cooling state based on the cooling mark of the target behavior.

3. The method of claim 1, wherein, The context features of the target behavior are obtained by: obtaining event stream data from multiple data sources; based on the event stream data, context analysis is performed to obtain the frequency related information, time related information and hit record information of the target behavior as context features.

4. The method of claim 1, wherein, The dynamic setting of the cooling period corresponding to the target behavior according to the evaluation result comprises: dynamically setting the cooling period corresponding to the target behavior based on the risk level obtained by evaluation.

5. The method of claim 1, wherein, The dynamic setting of the cooling period corresponding to the target behavior according to the evaluation result comprises: determining the cooling period corresponding to the target behavior as the reference time length based on the risk level obtained by evaluation; screening one or more key information from the context features, the key information being used to adjust the cooling period length; based on one or more key information, dynamically adjusting the reference time length to obtain the cooling period corresponding to the target behavior.

6. The method of claim 4 or 5, wherein, The method further comprises: using a machine learning model to predict the probability of triggering the execution of risk processing again in a future predetermined period of time based on the context features, and setting the cooling period accordingly based on the probability.

7. The method of claim 1, wherein, The risk evaluation based on the context features and the corresponding risk processing comprises: according to the context features, evaluating the risk level corresponding to the target behavior; based on the pre-stored risk processing strategy, performing one or more risk processing operations matched with the risk level.

8. The method of claim 7, wherein, According to the context features, evaluating the risk level corresponding to the target behavior comprises: using a trained machine learning model to output a corresponding risk evaluation result based on the context features, the risk evaluation result including the determination result of whether the target behavior is a risk behavior that needs intervention and the risk level of the risk behavior.

9. A risk processing system, characterized by It comprises: event collection end, for collecting the generated target behavior event; policy server, for executing the method of any one of claims 1 to 8; execution end, for executing corresponding risk disposal according to the instruction from the policy server.

10. An apparatus for risk processing, wherein, The device comprises: a feature acquisition module for obtaining context features of the target behavior in response to detecting the target behavior; a cooling judgment module for determining whether to trigger risk processing based on the cooling state of the target behavior; a risk evaluation module for evaluating the risk based on the context features and performing corresponding risk processing if risk processing is triggered; a cooling update module for dynamically setting the cooling period corresponding to the target behavior according to the evaluation result.

11. An electronic device, comprising: at least one processor; and a memory in communication with the at least one processor; wherein the memory has stored instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 8.

12. A computer readable medium having stored thereon computer program instructions executable by a processor to implement the method of any one of claims 1 to 8.

13. A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1 to 8.

Images