Artificial intelligence-based request processing method and apparatus, computer device, and medium

Abstract

The application belongs to the technical field of artificial intelligence, and relates to a request processing method and device based on artificial intelligence, computer equipment and a medium, which comprises the following steps: filtering request data based on a filtering tool to obtain first request data; generating access behavior data based on second request data obtained by preprocessing the first request data; performing feature extraction and screening on the second request data to obtain target feature data; performing prediction processing on the target feature data based on a risk prediction model and an anomaly prediction model to obtain first prediction results and second prediction results; fusing the first prediction data and the second data to obtain risk score data; performing action decision on the risk score data based on a strategy composer to obtain a response action; and responding to the first request data based on the response action. The application can be applied to a request processing scene in the field of financial technology, effectively improves the attack detection efficiency for requests, and improves the accuracy of attack detection.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology and can be applied to the financial technology field, particularly to request processing methods, devices, computer equipment, and storage media based on artificial intelligence. Background Technology

[0002] In the traditional online service model of the insurance industry, the processing of requests for insurance purchase, payment, and policy services on e-commerce platforms such as insurance malls mainly relies on rule-based attack detection mechanisms. This type of method statically matches request parameters and behavioral patterns using a pre-set rule base, which has significant technical drawbacks: First, updating the rule base depends on human experience and is difficult to cover new attack variants, resulting in low detection efficiency and an inability to respond in real time to emerging threats such as zero-day attacks; second, fixed rules are prone to misjudging normal business requests (such as mistakenly blocking high-frequency business queries), leading to a decrease in service availability. This "passive defense" model is no longer suitable for the increasingly complex attack environment in the financial and insurance sector.

[0003] Specifically, in payment request detection scenarios within the financial and insurance sectors, traditional methods typically only verify the format and validity of request parameters (such as the number of digits in a card number and the validity period of a verification code), lacking in-depth analysis of the context of the transaction behavior. For example, when using automated tools to initiate batch small-amount payment requests, traditional rule-based detection might allow them to proceed because the amount of a single transaction does not reach a threshold. However, if such requests are accompanied by abnormal device fingerprints (such as a batch of devices using the same hash) or are initiated in concentrated periods at high frequencies, they actually constitute a concealed fraud attack. This blind spot in detection not only leads to the loss of user funds but may also trigger regulatory compliance risks.

[0004] Therefore, there is an urgent need to build an intelligent request detection method to achieve accurate and efficient identification of attacks and improve the security protection effectiveness of insurance e-commerce platforms. Summary of the Invention

[0005] The purpose of this application is to propose a request processing method, apparatus, computer device, and storage medium based on artificial intelligence, so as to solve the technical problems of low detection efficiency and low accuracy of existing rule-based attack detection mechanisms.

[0006] Firstly, an artificial intelligence-based request processing method is provided, including: The request data to be processed is filtered based on a preset filtering tool to obtain the corresponding first request data; The first request data is preprocessed to obtain the second request data, and corresponding access behavior data is generated based on the second request data; Feature extraction is performed on the access behavior data to obtain corresponding feature data, and the feature data is filtered based on a preset discrete optimization feature type to obtain corresponding target feature data; The target feature data is processed by a preset risk prediction model to obtain a first prediction result, and the target feature data is processed by a preset anomaly prediction model to obtain a second prediction result. The first predicted data and the second data are fused together to obtain the corresponding risk score data. The risk score data is processed by a preset strategy orchestrator to obtain the corresponding response action. Based on the response action, the first requested data is processed accordingly.

[0007] Secondly, an artificial intelligence-based request processing device is provided, comprising: The filtering module is used to filter the request data to be processed based on a preset filtering tool to obtain the corresponding first request data. The generation module is used to preprocess the first request data to obtain the second request data, and generate corresponding access behavior data based on the second request data; The processing module is used to extract features from the access behavior data to obtain corresponding feature data, and to filter the feature data based on a preset discrete optimized feature type to obtain corresponding target feature data. The prediction module is used to perform prediction processing on the target feature data based on a preset risk prediction model to obtain a corresponding first prediction result, and to perform prediction processing on the target feature data based on a preset anomaly prediction model to obtain a corresponding second prediction result. The fusion module is used to fuse the first predicted data and the second data to obtain the corresponding risk score data; The decision module is used to perform action decision processing on the risk score data based on a preset strategy orchestrator to obtain the corresponding response action; The response module is used to perform corresponding response processing on the first request data based on the response action.

[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described artificial intelligence-based request processing method.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described artificial intelligence-based request processing method.

[0010] In the above-mentioned scheme implemented by the AI-based request processing method, apparatus, computer equipment, and storage medium, the request data to be processed is first filtered using a preset filtering tool to obtain corresponding first request data; then, the first request data is preprocessed to obtain second request data, and corresponding access behavior data is generated based on the second request data; subsequently, feature extraction is performed on the access behavior data to obtain corresponding feature data, and the feature data is filtered based on a preset discrete optimization feature type to obtain corresponding target feature data; subsequently, the target feature data is predicted using a preset risk prediction model to obtain a corresponding first prediction result, and the target feature data is predicted using a preset anomaly prediction model to obtain a corresponding second prediction result; the first prediction data and the second data are then fused to obtain corresponding risk score data; further, the risk score data is processed for action decision-making using a preset strategy orchestrator to obtain corresponding response actions; finally, the first request data is processed accordingly based on the response actions. Based on the above automated processing flow, unlike existing rule-based attack detection mechanisms, this application combines a multi-layered protection system of filtering tools, risk prediction models, anomaly prediction models, and policy orchestrators to achieve efficient and accurate attack detection processing of pending request data. This effectively improves the efficiency of attack detection and the accuracy of attack detection, thereby reducing the false positive rate. Attached Figure Description

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

[0012] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 This is a flowchart of an embodiment of the AI-based request processing method according to this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the AI-based request processing apparatus according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0014] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0016] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0017] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0018] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, and a desktop computer, etc.

[0019] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0020] It should be noted that the AI-based request processing method provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the AI-based request processing device is generally located in the server / terminal device.

[0021] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0022] Continue to refer to Figure 2 This document illustrates a flowchart of an embodiment of the AI-based request processing method according to this application. The order of steps in the flowchart can be changed, and some steps can be omitted, depending on different requirements. The AI-based request processing method provided in this application can be applied to any scenario requiring request processing, and therefore can be applied to products in these scenarios, such as request processing products in the financial insurance field. The AI-based request processing method includes the following steps: Step S201: Filter the request data to be processed based on a preset filtering tool to obtain the corresponding first request data.

[0023] In this embodiment, the AI-based request processing method runs on an electronic device (e.g., Figure 1The server / terminal device shown can obtain the request data to be processed via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra wideband) connections, and other currently known or future wireless connection methods.

[0024] Specifically, the aforementioned filtering tools can include CDN (Content Delivery Network) and WAF (Web Application Firewall). By using these two filtering tools to collaboratively filter all request data to be processed, high-risk requests targeting core business operations can be effectively blocked initially, preventing malicious traffic from impacting backend services (such as risk control, transactions, and data queries).

[0025] Specifically, CDN (Content Delivery Network) based filtering includes: IP blacklist rule configuration: A real-time connection is established with a third-party threat intelligence database on globally distributed CDN nodes. The threat intelligence database continuously updates the list of malicious IPs, and CDN nodes configure IP blacklist rules based on this list. When a request arrives, it first checks whether the source IP of the request is in the blacklist. If it is, access from that malicious IP is directly blocked, preventing requests from known malicious sources from entering the system at the source.

[0026] CC attack protection enabled: Set a threshold for requests per second per IP. CDN nodes will monitor the request frequency of each IP in real time. Once it is found that the request frequency of an IP exceeds the set threshold, these requests exceeding the threshold will directly return an error status code (such as 429 Too Many Requests) or trigger a CAPTCHA challenge, requiring the user to enter a CAPTCHA to continue accessing the site. This prevents malicious requests from impacting the server and protects the server's stability.

[0027] URL whitelist configuration: Define a list of legitimate request paths and configure it as a URL whitelist. When a request arrives, check if the requested path is in the whitelist. If it is not in the whitelist, return an error message (such as 404 NotFound) or perform a redirect to guide the user to the correct page, preventing unauthorized requests from entering the system and ensuring that only legitimate traffic can proceed to subsequent processing stages.

[0028] In addition, WAF (Web Application Firewall) based filtering includes: professional WAF tool deployment: select and deploy professional WAF (Web Application Firewall) tools that have powerful attack detection and protection capabilities.

[0029] Attack signature rule configuration: Configure rules for SQL injection, XSS (Cross-Site Scripting) detection, etc. The WAF will perform a detailed analysis of each request, checking for code snippets or data that match these attack signatures. Once an attack signature is detected, the request is directly intercepted, and detailed log information is recorded, including the request's source, time, and attack type, for subsequent analysis and tracing, preventing application-layer attacks from damaging the system.

[0030] Rate limiting rules enabled: Set trigger conditions for high-frequency access behavior, such as a threshold for the number of requests per unit time. When the WAF detects that the access frequency of a user or IP exceeds this threshold, it triggers a temporary blocking mechanism, prohibiting further access by that user or IP for a period of time to prevent brute-force attacks and protect system security.

[0031] GeoIP Database Integration: This feature integrates with the GeoIP database, which contains IP address information from various regions worldwide. The WAF queries the GeoIP database based on the source IP of the request to determine its origin. For requests from high-risk regions, it mandates CAPTCHA verification, increasing the difficulty of attacks and reducing the risk of attacks originating from high-risk areas.

[0032] Furthermore, this application can be applied to attack detection scenarios related to request processing in the financial and insurance field, and the following examples illustrate typical scenarios and processing logic of requests related to the financial and insurance field: Scenario 1: Batch Policy Information Scraping (Data Leakage Prevention). The request type for the above data requests can be: Policy Details Query Interface Request. Attack Characteristics: High-frequency scanning: The same IP initiates a large number of policy query requests in a short period of time (e.g., 100+ times per second), attempting to traverse the policy information in the database. Abnormal parameters: The request parameters contain randomly generated policy numbers (e.g., policy_id=RAND123456), or are missing necessary fields (e.g., user authentication information is not provided). IP associated with black market activities: This IP has been flagged as having participated in data scraping activities on other financial platforms.

[0033] CDN / WAF Processing Flow: Rate Limiting: CDN nodes rate-limit policy query requests from the same IP (e.g., a maximum of 20 requests per minute); exceeding this threshold triggers blocking. Parameter Validation: WAF checks whether request parameters conform to business logic (e.g., whether the policy number format is valid, and whether any necessary fields are missing). Behavioral Analysis: Combining with a threat intelligence database, if the IP has historical crawling records, a 403 Forbidden response is returned directly to prevent data leakage.

[0034] Business Impact: Protecting user policy information (such as coverage amount, beneficiary, and effective date) from being scraped by malicious actors and used for fraud or targeted marketing. Preventing backend database performance degradation due to high-frequency queries, which could impact normal user services.

[0035] Scenario 2: Automated Claims Fraud (Fake Claims Prevention). The request type for the above data requests can be: Claims Application Interface Request. Attack Characteristics: Abnormal Device Fingerprint: The request device fingerprint (such as Canvas hash, time zone, language settings) does not match the normal user behavior pattern (e.g., all requests have completely identical Canvas hashes). High-Frequency Submission: The same device submits a large number of claims applications in a short period of time (e.g., submitting 10 claims for different policies within 1 minute). Fake Material Characteristics: The claim materials uploaded in the request (such as medical certificates, accident photos) are batch-generated forged documents (e.g., duplicate file hash values).

[0036] CDN / WAF Processing Flow: Device Fingerprint Detection: The WAF parses the device information in the request header, compares it with the known normal user database, and identifies abnormal devices. File Hash Verification: CDN nodes perform hash calculations on the uploaded claim materials; if duplicate files are found, they are marked as high-risk. Two-factor authentication: Suspicious requests are returned with a 429 Too Many Requests error or require human verification (such as SMS verification code) to prevent mass fraud.

[0037] Business impact: Prevents the use of automated tools to submit bulk fraudulent claims and defraud insurance companies. Reduces the review burden on the backend risk control system (avoiding invalid claims from entering the manual review process).

[0038] Scenario 3: DDoS Attack (Service Availability Assurance). The request type for the above request data could be: Insurance Product Recommendation Interface Request. Attack Characteristics: Traffic Surge: A large number of requests flood in a short period of time (e.g., 100,000+ requests per second), targeting the insurance product recommendation interface, attempting to exhaust server resources. Abnormal Request Pattern: The request header lacks necessary fields (e.g., Accept-Language) or contains randomly generated parameters (e.g., product_id=RAND). Dispersed IP Distribution: Attack traffic originates from different IPs globally, but the behavior pattern is highly consistent (e.g., simultaneously accessing the same interface).

[0039] CDN / WAF Processing Flow: Traffic Scrubbing: CDN nodes filter out obviously abnormal traffic (such as requests without a User-Agent) through TCP / UDP interception, IP reputation databases, and other means. Dynamic Rate Limiting: Dynamic rate limiting strategies are implemented for recommended interfaces (such as adjusting thresholds based on server load), and requests exceeding the limit are dropped or queued. Attack Source Tracing: Data such as the distribution of attacking IPs and request frequency are recorded to allow the security team to analyze attack paths and adjust defense strategies.

[0040] Business Impact: Ensure the availability of core services such as insurance product recommendations and rate calculations to prevent business interruptions due to DDoS attacks. Prevent malicious occupation of backend computing resources, which could affect normal users' quote inquiries or insurance application processes.

[0041] Step S202: Preprocess the first request data to obtain the second request data, and generate corresponding access behavior data based on the second request data.

[0042] In this embodiment, the specific implementation process of preprocessing the first request data to obtain the second request data and generating corresponding access behavior data based on the second request data will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0043] Step S203: Extract features from the access behavior data to obtain corresponding feature data, and filter the feature data based on a preset discrete optimized feature type to obtain corresponding target feature data.

[0044] In this embodiment, the aforementioned discrete optimization feature type refers to the feature type corresponding to the key features determined during the model training process of the risk prediction model or anomaly prediction model. During model training, the discrete optimization feature selection process includes: searching for an optimal subset in the candidate feature set using a genetic algorithm (GA) or tabu search to select the features most influential on the detection target (e.g., distinguishing between normal and aggressive behavior). With the optimization objectives of maximizing detection accuracy (AUC) and minimizing false positive rate (FPR), redundant, irrelevant, or features that do not significantly improve model performance can be removed, allowing the model to focus on key features for learning, thus improving the model's fitting effect and generalization ability on the training set. Selecting a key feature subset (e.g., 30-50 key features) during training reduces the data dimensionality required for model training, lowers computational complexity, accelerates training, and saves training resources and time. Furthermore, the feature type of the generated key feature subset is used as the aforementioned discrete optimization feature type. Therefore, subsequently, based on the feature type of the optimal feature subset determined through discrete optimization during the training phase (i.e., the discrete optimized feature type), the above feature data can be filtered to obtain target feature data that matches the above discrete optimized feature type.

[0045] Furthermore, the specific implementation process of extracting features from the access behavior data to obtain the corresponding feature data will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0046] Step S204: Based on a preset risk prediction model, the target feature data is processed to obtain a first prediction result, and based on a preset anomaly prediction model, the target feature data is processed to obtain a second prediction result.

[0047] In this embodiment, the target feature data can be predicted using a trained risk prediction model, and a corresponding risk score (first prediction result) can be output. Similarly, the target feature data can be predicted using a trained anomaly prediction model, and a corresponding anomaly score (second prediction result) can be output.

[0048] The training and generation process of the aforementioned risk prediction model and anomaly prediction model will be described in more detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0049] Step S205: The first predicted data and the second data are fused to obtain the corresponding risk score data.

[0050] In this embodiment, the specific implementation process of fusing the first predicted data and the second data to obtain the corresponding risk score data will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0051] Step S206: Based on a preset strategy orchestrator, the risk score data is processed for action decision-making to obtain the corresponding response action.

[0052] In this embodiment, the risk score data is processed by a preset strategy orchestrator to obtain the specific implementation process of the corresponding response action. This application will describe this in more detail in subsequent specific embodiments, and will not elaborate further here.

[0053] Step S207: Perform corresponding response processing on the first request data based on the response action.

[0054] In this embodiment, the specific implementation process of responding to the first request data based on the response action will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0055] This application first filters the request data to be processed based on a preset filtering tool to obtain corresponding first request data; then, it preprocesses the first request data to obtain second request data, and generates corresponding access behavior data based on the second request data; next, it extracts features from the access behavior data to obtain corresponding feature data, and filters the feature data based on a preset discrete optimization feature type to obtain corresponding target feature data; subsequently, it performs prediction processing on the target feature data based on a preset risk prediction model to obtain corresponding first prediction results, and performs prediction processing on the target feature data based on a preset anomaly prediction model to obtain corresponding second prediction results; then, it fuses the first prediction data and the second data to obtain corresponding risk score data; further, it performs action decision processing on the risk score data based on a preset strategy orchestrator to obtain corresponding response actions; finally, it performs corresponding response processing on the first request data based on the response actions. Based on the above automated processing flow, unlike existing rule-based attack detection mechanisms, this application combines a multi-layered protection system of filtering tools, risk prediction models, anomaly prediction models, and policy orchestrators to achieve efficient and accurate attack detection processing of pending request data. This effectively improves the efficiency of attack detection and the accuracy of attack detection, thereby reducing the false positive rate.

[0056] In some alternative implementations, step S203 includes the following steps: The second requested data is subjected to feature classification and calculation to obtain the corresponding initial feature data.

[0057] In this embodiment, the initial feature data obtained after classifying and calculating the features of the second request data mentioned above may include: 1) Account Side: Number of registrations since today: New accounts are at higher risk (e.g., bulk registrations by "wool party" members). Number of failed login attempts in 24 hours: A direct indicator of brute-force attacks. Number of logins from multiple accounts on the same device: A typical characteristic of device sharing (e.g., black market data centers). Password recovery trigger rate: High-frequency triggering may indicate account theft.

[0058] 2) Device & Fingerprint: Fingerprint Consistency: Similarity of device fingerprints (such as browser version, screen resolution), used to identify automated tools. JS Execution Anomaly Count: A sign that the browser environment has been tampered with (e.g., JS is disabled). Headless Feature Ratio: Special behavioral patterns of headless browsers (such as Puppeteer). Canvas / Time Zone / Font Entropy: Detects device forgery through the randomness of Canvas drawing, time zone settings, and font libraries.

[0059] 3) Network: AS Number: Autonomous System Number, identifying data center IPs (e.g., AWS, Alibaba Cloud). IP Reputation: Historical records of malicious behavior (e.g., web crawlers, attack sources). Concurrency with the same prefix: Abnormal traffic bursts within the same IP segment (e.g., / 24). End-to-end RTT: Abnormal network latency (e.g., spoofed GPS location but RTT does not match the geographical location). Replay Indication: Duplicate cookies / tokens, potentially indicating session hijacking.

[0060] 4) Business Operations: Trial Calculation Frequency: High-frequency trial calculations (such as insurance quotes) may be fraudulent attempts. Trial Calculation Price Difference Entropy: Abnormal price sensitivity (such as repeated trial calculations of low-priced packages). Multiple Policyholders on the Same Device: Shared device insurance may be a group fraud. Abnormal Use of Promotional Coupons: Such as large-scale use of coupons in a short period of time. Payment Failure Code Distribution: Specific failure codes (such as frequent occurrences of "insufficient balance") may be malicious attempts.

[0061] 5) Flow Control: CAPTCHA Failure Rate per Unit Time: Devices with high human-machine verification failure rates may be subject to automated attacks. Risk Control Rule Hit Count: The number of triggered rules reflects the accumulation of risk. WAF Hit Cluster ID: Clustering of attack types blocked by the Web Application Firewall (e.g., SQL injection, XSS).

[0062] The initial feature data is integrated and processed to obtain the corresponding first feature data.

[0063] In this embodiment, all the obtained initial feature data can be integrated and processed, and the resulting feature dataset can be used as the corresponding first feature data.

[0064] The first feature data is subjected to feature engineering to obtain the corresponding second feature data.

[0065] In this embodiment, the feature engineering includes: 1) Feature construction: Combined features: such as "IP reputation + concurrent with the same prefix" can identify local attack outbreaks. Statistical features: such as "moving average of password retrieval trigger rate within 7 days" to smooth short-term fluctuations. 2) Feature screening: Business rule filtering: Eliminating features irrelevant to risk (such as "user gender" which is not helpful for fraud detection). Statistical testing: Screening features strongly correlated with tags (such as whether it is fraud) through methods such as chi-square test and mutual information. 3) Feature transformation: Discretization: Segmenting continuous features (such as "number of days since registration") into segments (such as "0-7 days" and "8-30 days"). Normalization: Scaling numerical features (such as "RTT") to the [0,1] interval to avoid the influence of units.

[0066] The second feature data is used as the feature data.

[0067] This application obtains corresponding initial feature data by performing feature classification and calculation on the second request data; then, it integrates the initial feature data to obtain corresponding first feature data; subsequently, it performs feature engineering on the first feature data to obtain corresponding second feature data; and finally, it uses the second feature data as the final feature data. Based on the above processing flow, this application achieves efficient and accurate feature extraction processing of the second request data by performing feature classification and calculation, integration, and feature engineering on the second request data, thereby improving the processing efficiency of feature extraction and ensuring the accuracy and diversity of the generated feature data.

[0068] In some optional implementations of this embodiment, step S205 includes the following steps: Obtain the preset weight generation strategy and the preset score fusion formula.

[0069] In this embodiment, the weight generation strategy includes assigning different weights to the two models based on their characteristics and historical performance. Specifically, the supervised learning model (risk prediction model) accurately identifies known attack patterns, so its weight can be set higher; the unsupervised learning model (anomaly prediction model) can detect unknown attack patterns, so its weight is also set appropriately. Furthermore, the scoring fusion formula is a weighted summation formula. Through weighted fusion, the advantages of both models are comprehensively considered to accurately generate the final risk score.

[0070] Based on the weight generation strategy, a first weight corresponding to the risk prediction model is generated, and a second weight corresponding to the anomaly prediction model is generated.

[0071] In this embodiment, the risk prediction model and the anomaly prediction model can be weighted based on the strategy content of the above weight generation strategy to obtain the first weight corresponding to the risk prediction model and generate the second weight corresponding to the anomaly prediction model.

[0072] The first prediction result, the second prediction result, the first weight, and the second weight are calculated based on the scoring fusion formula to obtain the corresponding calculation result.

[0073] In this embodiment, the first prediction result, the second prediction result, the first weight, and the second weight can be substituted into the above-mentioned scoring fusion formula for calculation, and the obtained calculation result can be used as the corresponding risk score data.

[0074] The calculation results are used as the risk score data.

[0075] This application obtains a preset weight generation strategy and a preset scoring fusion formula; then, based on the weight generation strategy, it generates a first weight corresponding to the risk prediction model and a second weight corresponding to the anomaly prediction model; subsequently, it calculates the first prediction result, the second prediction result, the first weight, and the second weight based on the scoring fusion formula to obtain the corresponding calculation result; finally, it uses the calculation result as the risk score data. Based on the above processing flow, this application uses a trained risk prediction model and anomaly prediction model to perform risk assessment on the feature-calculated request data to generate a corresponding risk score. Furthermore, by integrating the advantages of multiple models, it can more comprehensively and accurately assess the risk level of the request, ensuring the accuracy and comprehensiveness of the generated risk score data, which is beneficial for providing strong support for subsequent strategy selection.

[0076] In some optional implementations, the training and generation process of the above risk prediction model includes: 1. Data preparation. Data is collected from multiple channels such as platform CDN / WAF, Nginx, login / insurance / payment logs, device / JS fingerprints, risk control engine events, verification codes, and third-party payment callbacks. The collected data is preprocessed, including deduplication, normalization, and aggregation of the same session. To reduce data dimensionality, PCA or statistical dimensionality reduction can be performed first, and then discrete optimization methods such as genetic algorithms and particle swarm optimization can be used to search for feature subsets in a large number of candidates, using AUC, FPR@TPR, inference latency, etc. as evaluation indicators to form a high-dimensional candidate feature set. 2. Feature engineering. Features such as the number of registrations since today, the number of failed logins in 24 hours, the number of multiple account logins on the same device, and the password retrieval trigger rate are extracted from the account side. Features such as fingerprint consistency, JS execution anomaly count, headless feature ratio, and Canvas / time zone / font entropy are obtained from the device and fingerprint side. At the network level, features such as AS number, IP reputation, concurrent connections with the same prefix, end-to-end RTT, and replay indications (duplicate cookies / tokens) are extracted. At the business level, features such as trial calculation frequency, trial price difference entropy, multiple policyholders on the same device, abnormal use of promotional coupons, and payment failure code distribution are extracted. At the flow control level, features such as CAPTCHA failure rate per unit time, risk control rule hit count, and WAF hit cluster ID are extracted. 3. Model Training and Optimization. Based on decision trees, XGBoost, SVM, and other models, the risk prediction model is trained using the prepared feature data. Discrete optimization methods such as genetic algorithms, tabu search, or simulated annealing are used to optimize model parameters in the discrete space, such as tree depth, number of leaves, sample weights, field values, and cost matrix. The optimization objective is a multi-objective weighted approach, namely maximizing the true positive rate (TPR), minimizing the false positive rate (FPR), and minimizing the P95 latency. Evaluation is driven by cross-validation feedback. 4. Model Evaluation. The trained model is evaluated using k-fold cross-validation, with evaluation metrics including AUC, TPR, FPR, and latency. The model is then evaluated to determine if it meets the requirements. If not, the process returns to feature engineering or model parameter optimization steps until the model performance meets the standards, resulting in a well-constructed risk prediction model.

[0077] The training and generation process of the aforementioned anomaly prediction model includes: 1. Data preparation. Similar to supervised learning models, data is collected from multiple channels and preprocessed, including deduplication, normalization, aggregation of the same session, and possible dimensionality reduction and discrete optimization feature selection operations, forming a dataset suitable for unsupervised learning. 2. Feature engineering. Relevant features are extracted from multiple dimensions such as account, device & fingerprint, network, business, and flow control to construct a comprehensive feature system to capture various patterns and anomaly information in the data. 3. Model training. Unsupervised learning models such as Isolation Forest and One-Class SVM are used to train the model to detect zero-day attacks and irregular behaviors using the prepared feature data. These models can identify anomalous data points that deviate from the normal pattern by learning the normal distribution pattern of the data, even without labeled data. 4. Model evaluation. Although unsupervised learning does not have explicit labels for directly evaluating model performance, it can be evaluated through some indirect methods. For example, the abnormal data detected by the model can be manually analyzed to determine whether it is indeed an attack or irregular behavior, and the detection accuracy can be calculated. The effectiveness of the model can also be comprehensively evaluated by combining it with business metrics, such as the impact of detected abnormal behavior on business operations. Simultaneously, a k-fold cross-validation approach similar to supervised learning can be employed, dividing the dataset and training and validating on different subsets to more comprehensively assess the model's stability and generalization ability. Based on the evaluation results, the model can be adjusted and optimized, such as by adjusting its parameters, until the model can effectively detect zero-day attacks and unusual behaviors, resulting in a well-trained anomaly prediction model.

[0078] In some alternative implementations, step S206 includes the following steps: The strategy orchestrator invokes the strategy library obtained through discrete optimization search.

[0079] In this embodiment, the specific implementation process of calling the policy library obtained through discrete optimization search based on the policy orchestrator will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0080] Retrieve action strategies from the strategy library that match the risk score data.

[0081] In this embodiment, a rule engine can be used to quickly and accurately match the corresponding action strategy from the above-mentioned strategy library based on the input risk score data.

[0082] The action strategy is optimized based on preset optimization rules to obtain the corresponding target action strategy.

[0083] In this embodiment, the above-mentioned optimization rule refers to the context-aware rule. The rule content includes: adjusting the action strategy in combination with the business context. For example, during a promotional period, due to the large business traffic, in order not to affect the shopping experience of normal users, the CAPTCHA trigger threshold is lowered, that is, CAPTCHA verification is only triggered when the risk score is high. During the nighttime period, a manual review process is added for high-risk operations. Since there are relatively fewer people at night, manual review can more carefully judge whether the operation is legal, thereby improving the adaptability and flexibility of the action strategy.

[0084] Then, based on the rule content of the above optimization rules, the optimization processing of the above action strategy is performed, and the generated target action strategy is used as the corresponding response action.

[0085] The target action strategy is used as the response action.

[0086] This application utilizes a strategy orchestrator to access a strategy library obtained through discrete optimization search. It then queries the strategy library for action strategies matching the risk score data. Following this, the action strategies are optimized based on preset optimization rules to obtain a corresponding target action strategy. This target action strategy is then used as the response action. Based on this process, by using a strategy orchestrator and combining strategy library matching with optimization rule-based strategy optimization, this application can dynamically select the optimal response action, thereby automating and intelligently handling the risk of requested data. Furthermore, through dynamic decision-making and context awareness, it can ensure security while also considering user experience.

[0087] In some optional implementations, the step of calling the policy library obtained through discrete optimization search based on the policy orchestrator includes the following steps: Obtain predefined risk scenarios and response actions, as well as pre-built optimization objective functions.

[0088] In this embodiment, the system pre-defines the optimization elements and scenario divisions. The implementation process includes: Risk scenario division: The system meticulously divides risk scenarios from multiple dimensions. Requests are divided into different risk ranges based on their risk level, such as low-risk, medium-risk, and high-risk ranges; the source entry point of the request is identified, as different entry points may face different types of attacks and risks; User Agents (UAs) and device fingerprints are classified and combined to form UA / fingerprint clusters, because different devices and browsers may have different behavioral patterns, and these differences help to more accurately determine risks.

[0089] Define response actions: Discretize the response "actions" that the system can take and define them as a series of specific operation combinations, such as allowing (not restricting normal requests), rate limiting (limiting the frequency of requests, with r representing the specific limit value), challenge (verifying the legitimacy of requests through CAPTCHA verification codes, slider verification, SMS verification, etc.), login freezing (restricting login to suspicious accounts, with t representing the freeze duration), WAF rule set number (applying a specific Web Application Firewall rule set, with k representing the specific rule set number), etc.

[0090] Furthermore, the process of constructing the optimization objective function includes: multi-objective trade-offs: the optimization objective is not a single metric, but rather considers multiple key metrics simultaneously. This includes minimizing conversion loss, i.e., avoiding losses caused by overly strict response strategies that prevent normal user transactions from being completed; minimizing attack residue rate, i.e., reducing the proportion of attacks that are not effectively intercepted; simultaneously constraining the complaint rate to prevent users from filing numerous complaints due to dissatisfaction with the response strategy; and also constraining the amount of manual review to reduce the number of requests requiring manual intervention, thereby improving processing efficiency and reducing costs. Optimization objective function construction: these objectives are quantified and constructed into a comprehensive optimization objective function. For example, each objective can be assigned a weight, and they can be weighted and summed, or other suitable combinations can be used to form a function that comprehensively reflects the advantages and disadvantages of the strategy.

[0091] Based on the risk scenario and the response action, a preset discrete optimization algorithm is used to perform search processing to generate the corresponding initial strategy combination.

[0092] In this embodiment, the implementation process of using discrete optimization algorithms for search processing includes: employing algorithms suitable for optimization in discrete space, such as genetic algorithms (GA), tabu search, and simulated annealing. These algorithms each have their own characteristics. Genetic algorithms simulate biological evolution, gradually optimizing strategy combinations through selection, crossover, and mutation. Tabu search avoids repeated searches by recording already searched local optima, thus escaping local optima. Simulated annealing, drawing on the principle of solid annealing, accepts poor solutions with a certain probability, increasing the likelihood of finding the global optimum. Furthermore, after selecting the required discrete optimization algorithm (which can be simply referred to as the algorithm) according to the implementation requirements, the algorithm randomly generates an initial set of strategy combinations (or action strategies) when it starts running. These combinations include the selection of response actions for different risk ranges, entry points, and user agent / fingerprint clusters.

[0093] Based on the optimization objective function, the initial strategy combination is iteratively optimized to obtain the corresponding first strategy combination.

[0094] In this embodiment, the iterative optimization process includes: a discrete optimization algorithm evaluating the initial strategy combination based on the objective function, and generating new strategy combinations according to their respective rules based on the evaluation results. For example, a genetic algorithm selects strategy combinations with better performance for crossover and mutation operations to generate new offspring strategy combinations; tabu search explores the neighborhood of the current solution to find better solutions while avoiding reverting to solutions that are already taboo; simulated annealing accepts solutions worse than the current solution with a certain probability, gradually converging to the optimal solution as the temperature decreases. Through this iterative process, the optimal strategy combination is gradually approximated.

[0095] The first strategy combination is evaluated and adjusted based on a preset verification method to obtain the corresponding second strategy combination.

[0096] In this embodiment, the aforementioned verification method specifically employs cross-validation. During the search process, strategy combinations are evaluated using cross-validation. The dataset is divided into multiple subsets, with one subset used as the training set and the remainder as the validation set in turn. The performance of the strategy combinations on the validation set, such as conversion loss, attack residual rate, complaint rate, and manual review volume, is used to evaluate the quality of the strategy combinations. Dynamic adjustments and optimizations are then performed: based on the feedback results of cross-validation, the algorithm dynamically adjusts the search direction and strategy combinations. If a strategy combination performs poorly on the validation set, the algorithm reduces the probability of generating similar combinations; conversely, if it performs well, its chances of being selected are increased, or further optimization exploration is conducted based on it. Through this feedback-driven approach, strategy combinations are continuously optimized, ultimately resulting in an optimal strategy combination library for different risk scenarios.

[0097] The second strategy combination is stored in a preset database to obtain the corresponding strategy library, and the strategy library is called based on the strategy orchestrator.

[0098] In this embodiment, the strategy library is constructed by storing the generated second strategy combination in a blank database so that the subsequent strategy orchestrator can call it.

[0099] This application obtains predefined risk scenarios and response actions, as well as a pre-constructed optimization objective function. Then, based on the risk scenarios and response actions, it uses a preset discrete optimization algorithm to perform a search process to generate a corresponding initial strategy combination. Next, it iteratively optimizes the initial strategy combination based on the optimization objective function to obtain a corresponding first strategy combination. Subsequently, it evaluates and adjusts the first strategy combination based on a preset verification method to obtain a corresponding second strategy combination. Finally, it stores the second strategy combination in a preset database to obtain a corresponding strategy library, and calls the strategy library based on the strategy orchestrator. Based on the above processing flow, this application generates an initial strategy combination by using a preset discrete optimization algorithm to perform a search process based on predefined risk scenarios and response actions, iteratively optimizes the initial strategy combination based on the obtained optimization objective function to obtain a first strategy combination, and then evaluates and adjusts the first strategy combination based on the verification method to obtain a second strategy combination. Thus, this application utilizes a discrete strategy searcher to automatically optimize strategies through machine learning algorithms, overcoming the limitations of manual parameter tuning. It can dynamically adjust strategies based on real-time data, making the strategies more adaptable to the constantly changing risk environment and business needs, improving the effectiveness and efficiency of risk management. Furthermore, the second strategy combination will be stored in a preset database, thereby enabling the dynamic and intelligent completion of the strategy library construction process.

[0100] In some optional implementations of this embodiment, step S207 includes the following steps: Obtain the preset action coordination and processing strategy.

[0101] In this embodiment, the above-mentioned action coordination and processing strategy includes: Distributed lock usage: Using distributed locks to ensure that the same user does not trigger multiple actions simultaneously. For example, when a user is performing CAPTCHA verification, a distributed lock prevents the user from triggering other restriction or blocking actions simultaneously, avoiding action conflicts. Action priority setting: Setting action priorities, for example, blocking actions have the highest priority, verification actions are next, restriction actions are next, and notification actions have the lowest priority. When multiple actions are triggered simultaneously, the actions are executed according to their priority order to ensure orderly risk handling.

[0102] Based on the action coordination and processing strategy, the response action is optimized to obtain the corresponding target response action.

[0103] In this embodiment, action optimization processing for the above-mentioned response action can be performed based on the strategy content of the above-mentioned action coordination processing strategy to obtain the corresponding target response action.

[0104] Based on the target response action, the first request data is processed accordingly.

[0105] In this embodiment, the above response processing may include: For blocking actions: based on using distributed locks and setting action priorities, directly return an error status code, for example, when a request is determined to be a high-risk malicious request, directly return an error status code such as 403 Forbidden to prevent further processing of the request; close the TCP connection, for some serious malicious attacks, directly close the TCP connection with the client and cut off communication.

[0106] Verification actions: Based on the use of distributed locks and the setting of action priorities, such as returning a verification code challenge, requiring the user to enter a graphic verification code or SMS verification code for verification; requiring secondary verification via SMS / email, sending a verification link or verification code to the user's bound mobile phone or email address, and the user can only continue to operate after completing the verification, ensuring that the request is initiated by a legitimate user.

[0107] Restrictive actions: Based on using distributed locks and setting action priorities, reduce the request frequency, such as limiting the number of requests a user can make within a certain time (e.g., per minute); restrict the scope of operations, such as restricting users to only perform certain specific operations in the system to prevent malicious or excessive operations.

[0108] Notification actions: Based on the use of distributed locks and the setting of action priorities, send alarm emails / SMS to the risk control team. When high-risk requests or abnormal situations occur, promptly notify risk control personnel for handling; record detailed logs for subsequent analysis, including detailed information about the request, risk score, and handling actions, so as to trace and analyze risk events later.

[0109] This application obtains a preset action coordination and processing strategy; then, based on the action coordination and processing strategy, it optimizes the response action to obtain a corresponding target response action; subsequently, it performs corresponding response processing on the first request data based on the target response action. Based on the above processing flow, this application effectively ensures system security by performing actual risk management on requests according to the response action selected by the strategy orchestrator. Simultaneously, through a reasonable action coordination mechanism, it minimizes the impact on normal users while ensuring system security, thereby improving user experience.

[0110] In some optional implementations of this embodiment, step S202 includes the following steps: The first request data is deduplicated to obtain the corresponding specified request data.

[0111] In this embodiment, the deduplication process refers to merging duplicate requests to eliminate redundant data caused by network retries, attackers sending the same requests in batches, etc. The specific implementation process includes: defining the criteria for determining duplicate requests: Identical requests: Source IP + request path + request body + timestamp (second level) are completely identical. Similar requests: Such as requests with the same path but different parameter values ​​(e.g., / login?user=A and / login?user=B), can be merged using hashing or regular expressions. Deduplication methods: Hash deduplication: Generate a unique hash value (e.g., MD5) for each request and store it in a temporary set (e.g., Redis Set). If the hash already exists, discard the new request. Sliding window counting: Count the number of times the same request appears within a fixed time window (e.g., 1 minute), and only retain the first occurrence of the request.

[0112] The specified request data is normalized to obtain the corresponding second request data.

[0113] In this embodiment, the normalization process includes: 1) unifying the timestamp format to ensure consistency in timestamp formats across different systems (CDN, WAF, backend services) for easier time-series analysis. 2) normalizing numerical features using quantile scaling to eliminate dimensional differences between features (e.g., the number of failed login attempts ranges from 0 to 100, while the request frequency ranges from 0 to 1000), enabling the model to process them fairly. 3) encoding categorical features using label encoding or one-hot encoding to convert non-numerical features (e.g., interception types IP / CC / URL) into a format that the model can process.

[0114] Call the preset backend service.

[0115] In this embodiment, the selection of the aforementioned backend services is not specifically limited and can be determined according to actual business needs; for example, an application server can be used.

[0116] The backend service generates access behavior data corresponding to the second request data.

[0117] In this embodiment, the second request data can be processed by logging according to the selected backend service to obtain corresponding access behavior data, i.e., access logs. The access behavior data may include at least: User identifier: User ID (unique identifier), Session ID; Behavioral data: Request path, HTTP method (GET / POST), response status code (200 / 500), request time; Device information: IP address, device fingerprint (browser type, screen resolution), geolocation (resolved via GeoIP). The consumed log data can be aggregated according to the user session dimension. A session timeout is set, for example, 30 minutes. When a user makes no new requests within 30 minutes, a session is considered to have ended. During session aggregation, key fields such as User ID, IP, device fingerprint, request path, response status code, and timestamp are parsed for each log entry. Furthermore, the generated access logs are the core data source for subsequent feature calculations, used to extract user behavior features.

[0118] This application deduplicates the first request data to obtain corresponding specified request data; then normalizes the specified request data to obtain corresponding second request data; subsequently, a preset backend service is invoked; and then access behavior data corresponding to the second request data is generated based on the backend service. Based on the above processing flow, this application, by deduplicated and normalized the first request data, can automatically and accurately complete the preprocessing of the first request data, ensuring the accuracy and standardization of the obtained second request data. Furthermore, based on the use of the backend service, access behavior data corresponding to the second request data is automatically generated, serving as the core data source for subsequent feature calculations.

[0119] In some optional implementations, this application also features feedback and adaptive update capabilities, the specific implementation process of which includes: 1. Data Collection. Multiple data types are recorded: Interception results are recorded, including detailed information about the intercepted request and the reason for the interception; manually reviewed data is recorded after the system intercepts a request, with feedback and results recorded; complaint data is collected, including user complaints about system interception or restriction of operations. Data Storage and Processing: Structured data (such as interception results and structured fields from manually reviewed data) is written into a data lake for subsequent querying and analysis. Unstructured data (such as the text content of user complaints) is processed using NLP (Natural Language Processing) to extract and tag keywords, such as extracting keywords like the reason for the complaint and the relevant business modules from the complaint text, providing rich data support for model iteration.

[0120] 2. Data Feedback. Data updates models and strategies: Processed data is fed back into the system to update models and strategies. For example, the model is retrained using new intercepted data and manually reviewed data, and the model's parameters and feature weights are adjusted; based on the problems and trends reflected in the data, strategies in the strategy library are adjusted to ensure that models and strategies can adapt to new attacks and business changes in a timely manner.

[0121] 3. Model Iteration. Regular Retraining: Retrain the model periodically (e.g., weekly or monthly) with new data, updating feature weights to enable the model to learn the latest data features and attack patterns. False Blocking Case Analysis: Perform root cause analysis on false blocking cases to identify the reasons for the false blocking, such as inaccurate feature calculation or unreasonable model threshold settings. Adjust the feature calculation logic or model parameters based on the analysis results to improve the model's accuracy and reliability, reducing false and missed blocking.

[0122] In some alternative implementations, the user information obtained is subject to user consent and complies with relevant laws and policies.

[0123] Furthermore, any software tools or components not belonging to our company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0124] Furthermore, this application has the following advantages: 1. Efficient feature selection: Key features are automatically selected through discrete optimization, reducing redundancy and improving model detection efficiency; 2. Improved detection accuracy: By combining supervised and unsupervised learning, the ability to detect known attacks and zero-day attacks is improved; 3. End-to-end protection: From entry inspection and risk warning to automatic blocking, a multi-layered protection system is formed.

[0125] 4. Reduce false alarms: By using a dual threshold mechanism (early warning threshold + defense threshold), avoid "one-size-fits-all" treatment of normal users.

[0126] 5. Adaptive optimization: Early warning and defense results are fed back to the training module, forming a continuous evolution capability.

[0127] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0128] It should be emphasized that, to further ensure the privacy and security of the aforementioned risk scoring data, the risk scoring data can also be stored in a blockchain node.

[0129] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0130] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results. Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0131] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0132] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0133] Further reference Figure 3 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of an artificial intelligence-based request processing device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0134] like Figure 3 As shown, the AI-based request processing device 300 described in this embodiment includes: a filtering module 301, a generation module 302, a processing module 303, a prediction module 304, a fusion module 305, a decision-making module 306, and a response module 307. Wherein: The filtering module 301 is used to filter the request data to be processed based on a preset filtering tool to obtain the corresponding first request data. The generation module 302 is used to preprocess the first request data to obtain the second request data, and generate corresponding access behavior data based on the second request data; The processing module 303 is used to extract features from the access behavior data to obtain corresponding feature data, and to filter the feature data based on a preset discrete optimized feature type to obtain corresponding target feature data. The prediction module 304 is used to perform prediction processing on the target feature data based on a preset risk prediction model to obtain a corresponding first prediction result, and to perform prediction processing on the target feature data based on a preset anomaly prediction model to obtain a corresponding second prediction result. The fusion module 305 is used to fuse the first prediction data and the second data to obtain the corresponding risk score data. The decision module 306 is used to perform action decision processing on the risk score data based on a preset strategy orchestrator to obtain the corresponding response action; The response module 307 is used to perform corresponding response processing on the first request data based on the response action.

[0135] In some optional implementations of this embodiment, the processing module 303 includes: The first processing submodule is used to perform feature classification and calculation on the second request data to obtain the corresponding initial feature data. An integration submodule is used to integrate the initial feature data to obtain the corresponding first feature data; The second processing submodule is used to perform feature engineering on the first feature data to obtain the corresponding second feature data. The first determining submodule is used to use the second feature data as the feature data.

[0136] In some optional implementations of this embodiment, the fusion module 305 includes: The first acquisition submodule is used to acquire the preset weight generation strategy and the preset score fusion formula; The first generation submodule is used to generate a first weight corresponding to the risk prediction model based on the weight generation strategy, and to generate a second weight corresponding to the anomaly prediction model. The calculation submodule is used to perform calculations on the first prediction result, the second prediction result, the first weight, and the second weight based on the scoring fusion formula to obtain the corresponding calculation results. The second determining submodule is used to use the calculation result as the risk score data.

[0137] In some optional implementations of this embodiment, the decision module 306 includes: The first invocation submodule is used to invoke the strategy library obtained through discrete optimization search based on the strategy orchestrator; The query submodule is used to query the strategy library for action strategies that match the risk score data; The optimization submodule is used to optimize the action strategy based on preset optimization rules to obtain the corresponding target action strategy. The third determining submodule is used to take the target action strategy as the response action.

[0138] In some optional implementations of this embodiment, calling the submodule includes: The acquisition unit is used to acquire predefined risk scenarios and response actions, as well as pre-built optimization objective functions; The search unit is used to perform search processing based on the risk scenario and the response action using a preset discrete optimization algorithm to generate a corresponding initial strategy combination. An optimization unit is used to perform iterative optimization on the initial strategy combination based on the optimization objective function to obtain the corresponding first strategy combination. The first processing unit is used to evaluate and adjust the first strategy combination based on a preset verification method to obtain a corresponding second strategy combination. The second processing unit is used to store the second strategy combination into a preset database to obtain a corresponding strategy library, and to call the strategy library based on the strategy orchestrator.

[0139] In some optional implementations of this embodiment, the response module 307 includes: The second acquisition submodule is used to acquire preset action coordination and processing strategies; The third processing submodule is used to perform action optimization processing on the response action based on the action coordination processing strategy to obtain the corresponding target response action; The response submodule is used to perform corresponding response processing on the first request data based on the target response action.

[0140] In some optional implementations of this embodiment, the generation module 302 includes: The fourth processing submodule is used to perform deduplication on the first request data to obtain the corresponding specified request data; The fifth processing submodule is used to normalize the specified request data to obtain the corresponding second request data; The second submodule is used to call preset backend services; The second generation submodule is used to generate access behavior data corresponding to the second request data based on the backend service.

[0141] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0142] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0143] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0144] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may also include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions for request processing methods based on artificial intelligence. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.

[0145] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions of the AI-based request processing method.

[0146] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.

[0147] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the artificial intelligence-based request processing method described above.

[0148] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0149] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A request processing method based on artificial intelligence, characterized in that, Includes the following steps: The request data to be processed is filtered based on a preset filtering tool to obtain the corresponding first request data; The first request data is preprocessed to obtain the second request data, and corresponding access behavior data is generated based on the second request data; Feature extraction is performed on the access behavior data to obtain corresponding feature data, and the feature data is filtered based on a preset discrete optimization feature type to obtain corresponding target feature data; The target feature data is processed by a preset risk prediction model to obtain a first prediction result, and the target feature data is processed by a preset anomaly prediction model to obtain a second prediction result. The first predicted data and the second data are fused together to obtain the corresponding risk score data. The risk score data is processed by a preset strategy orchestrator to obtain the corresponding response action. Based on the response action, the first requested data is processed accordingly.

2. The request processing method based on artificial intelligence according to claim 1, characterized in that, The step of extracting features from the access behavior data to obtain corresponding feature data specifically includes: The second request data is subjected to feature classification and calculation to obtain the corresponding initial feature data; The initial feature data is integrated and processed to obtain the corresponding first feature data; Perform feature engineering on the first feature data to obtain the corresponding second feature data; The second feature data is used as the feature data.

3. The request processing method based on artificial intelligence according to claim 1, characterized in that, The step of fusing the first predicted data and the second data to obtain the corresponding risk score data specifically includes: Obtain the preset weight generation strategy and the preset score fusion formula; Based on the weight generation strategy, a first weight corresponding to the risk prediction model is generated, and a second weight corresponding to the anomaly prediction model is generated. Based on the scoring fusion formula, the first prediction result, the second prediction result, the first weight, and the second weight are calculated to obtain the corresponding calculation result; The calculation results are used as the risk score data.

4. The request processing method based on artificial intelligence according to claim 1, characterized in that, The step of performing action decision processing on the risk score data based on a preset strategy orchestrator to obtain the corresponding response action specifically includes: The strategy orchestrator calls the strategy library obtained through discrete optimization search; Retrieve action strategies from the strategy library that match the risk score data; The action strategy is optimized based on preset optimization rules to obtain the corresponding target action strategy; The target action strategy is used as the response action.

5. The request processing method based on artificial intelligence according to claim 4, characterized in that, The step of calling the policy library obtained through discrete optimization search based on the policy orchestrator specifically includes: Obtain predefined risk scenarios and response actions, as well as pre-built optimization objective functions; Based on the risk scenario and the response action, a preset discrete optimization algorithm is used to perform search processing to generate the corresponding initial strategy combination; Based on the optimization objective function, the initial strategy combination is iteratively optimized to obtain the corresponding first strategy combination; The first strategy combination is evaluated and adjusted based on a preset verification method to obtain the corresponding second strategy combination; The second strategy combination is stored in a preset database to obtain the corresponding strategy library, and the strategy library is called based on the strategy orchestrator.

6. The request processing method based on artificial intelligence according to claim 1, characterized in that, The step of performing corresponding response processing on the first request data based on the response action specifically includes: Obtain preset action coordination and processing strategies; Based on the action coordination and processing strategy, the response action is optimized to obtain the corresponding target response action; Based on the target response action, the first request data is processed accordingly.

7. The request processing method based on artificial intelligence according to claim 1, characterized in that, The step of preprocessing the first request data to obtain the second request data, and generating corresponding access behavior data based on the second request data, specifically includes: The first request data is deduplicated to obtain the corresponding specified request data; The specified request data is normalized to obtain the corresponding second request data; Call the preset backend service; The backend service generates access behavior data corresponding to the second request data.

8. A request processing device based on artificial intelligence, characterized in that, include: The filtering module is used to filter the request data to be processed based on a preset filtering tool to obtain the corresponding first request data. The generation module is used to preprocess the first request data to obtain the second request data, and generate corresponding access behavior data based on the second request data; The processing module is used to extract features from the access behavior data to obtain corresponding feature data, and to filter the feature data based on a preset discrete optimized feature type to obtain corresponding target feature data. The prediction module is used to perform prediction processing on the target feature data based on a preset risk prediction model to obtain a corresponding first prediction result, and to perform prediction processing on the target feature data based on a preset anomaly prediction model to obtain a corresponding second prediction result. The fusion module is used to fuse the first predicted data and the second data to obtain the corresponding risk score data; The decision module is used to perform action decision processing on the risk score data based on a preset strategy orchestrator to obtain the corresponding response action; The response module is used to perform corresponding response processing on the first request data based on the response action.

9. A computer device, characterized in that, The system includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor, when executing the computer-readable instructions, implements the steps of the artificial intelligence-based request processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the artificial intelligence-based request processing method as described in any one of claims 1 to 7.

Images