An HTTP intelligent parameter variable sensing and directional matching method and device

Abstract

The application belongs to the technical field of data processing, and specifically discloses an HTTP intelligent parameter change perception and directional matching method and device, which comprises the following steps: first, inputting a call data D1, extracting a URL and storing it in a prefix tree; second, splitting the URL into path segments, parameter names, parameter values and other subfields according to a preset rule, calculating the subfield scores by using a BM25F algorithm, and storing the high-correlation-degree fields in a field library F1; third, filtering the D1 by using a preset content recognition rule library R1, retaining the effective call to form a call library D2; and finally, statistically analyzing the D2, detecting the deviation of data indexes such as the number of customers and the growth rate, and triggering the R1 to update when the deviation exceeds the limit. The application replaces the traditional manual analysis, improves the HTTP parameter change perception efficiency and accuracy, adapts to the growth demand of fields, and guarantees the data processing quality in scenarios such as Web service and API communication.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to an HTTP intelligent parameter change sensing and directional matching method and apparatus. Background Technology

[0002] With the rapid development of internet technology, the HTTP protocol, as the core mechanism for data exchange, plays a crucial role in scenarios such as web services, API communication, and mobile applications. HTTP requests and responses contain a large number of fields, which not only carry data content but also contain rich metadata, such as user identifiers, request parameters, and response status.

[0003] Traditionally, extracting features from HTTP fields has relied heavily on manual methods. Developers need to examine each field in HTTP requests and responses, manually determining their importance based on their name, description, and contextual information, and then proceeding with subsequent data processing accordingly. However, as web applications become increasingly complex, the number and types of HTTP fields are also growing rapidly. Faced with increasing traffic and changing content, manual analysis alone is no longer sufficient to accurately and promptly uncover new rules. Summary of the Invention

[0004] To address this issue, the present invention provides an HTTP intelligent parameter variation sensing and directional matching method, apparatus, electronic device, medium, and computer program product to solve the aforementioned technical problems.

[0005] This invention provides an HTTP intelligent parameter variation awareness and targeted matching method, comprising the following steps:

[0006] Get the input call detail record data D1, extract the corresponding URL and store it using a prefix tree;

[0007] The URL is split into multiple subfields based on preset rules, the score of each subfield is calculated based on the BM25F algorithm, and the highly relevant fields are stored in the attention field library F1. The subfields include path segments, parameter names, and parameter values.

[0008] Based on the preset content recognition rule base R1, filter call detail record data D1, and retain valid call detail records to form call detail record base D2;

[0009] The dialog box library D2 performs data statistics and analysis, detects deviations in data indicators, and triggers an update to the content recognition rule library R1 when the deviation exceeds the limit. The data indicators mentioned include at least: number of customers, growth rate, retention rate, customer regional distribution ratio, and average usage time per person.

[0010] In another aspect, this application also provides an HTTP intelligent parameter change sensing and directional matching device, comprising:

[0011] The call detail record (CDR) data acquisition module is used to acquire input CDR data D1, extract the corresponding URL, and store it using a prefix tree.

[0012] The module for building the focus field library is used to split the URL into multiple subfields based on preset rules, calculate the score of each subfield based on the BM25F algorithm, and store the highly relevant fields into the focus field library F1. The subfields include path segments, parameter names, and parameter values.

[0013] The call detail record (CDR) database generation module is used to filter CDR data D1 based on a preset content recognition rule base R1 and retain valid CDRs to form a CDR database D2.

[0014] The rule base update module is used for data statistics and analysis of the dialog single library D2, to detect deviations in data indicators, and to trigger an update of the content recognition rule base R1 when the deviation exceeds the limit. The data indicators mentioned include at least: number of customers, growth rate, retention rate, customer regional distribution ratio, and average usage time per person.

[0015] In another aspect, this application also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores 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 an HTTP intelligent parameter perception and directional matching method as described above.

[0016] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement an HTTP intelligent parameter change perception and targeted matching method as described above.

[0017] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements an HTTP intelligent parameter change perception and targeted matching method as described above.

[0018] The HTTP intelligent parameter variation awareness and targeted matching method provided by this invention effectively solves the problems of traditional HTTP field analysis, which relies on manual intervention, is inefficient, and struggles to adapt to increasing field size. It automatically extracts important fields by storing URLs using a prefix tree and filtering high-value fields using the BM25F algorithm. It combines a Transformer model to generate and optimize content recognition rules, along with multi-dimensional deviation verification, ensuring rule accuracy. Furthermore, it dynamically detects data deviations using a moving average smoothing method, triggering rule base updates. Overall, it reduces manual intervention, improves the efficiency and accuracy of HTTP parameter variation awareness, and ensures the quality and timeliness of data processing in scenarios such as Web services and API communication. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0021] Figure 1 This is a flowchart of an HTTP intelligent parameter change perception and targeted matching method provided in an embodiment of the present invention.

[0022] Figure 2 A schematic diagram of the Transformer model architecture is provided for embodiments of the present invention.

[0023] Figure 3 This is a schematic diagram of an HTTP intelligent parameter sensing and directional matching device provided in an embodiment of the present invention.

[0024] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The technical solutions of this application will be described in detail below with reference to various embodiments.

[0027] like Figure 1 As shown in the figure, an embodiment of the present invention discloses an HTTP intelligent parameter variation perception and targeted matching method 100, which includes the following method steps:

[0028] S101, obtain input call detail record data D1, extract the corresponding URL and store it using a prefix tree.

[0029] S102, based on preset rules, the URL is split into multiple subfields, the score of each subfield is calculated based on the BM25F algorithm, and the highly relevant fields are stored in the attention field library F1, wherein the subfields include path segments, parameter names, and parameter values;

[0030] S103, filter call detail record data D1 based on the preset content recognition rule base R1, and retain valid call detail records to form a call detail record base D2;

[0031] S104, the dialog single library D2 performs data statistics and analysis, detects deviations in data indicators, and triggers an update to the content recognition rule library R1 when the deviation exceeds the limit. The data indicators mentioned include at least: number of customers, growth rate, retention rate, customer regional distribution ratio, and average usage time per person.

[0032] In one embodiment, for S101, the call detail record (CDR) data generated by the target web service, API interface, or mobile application is first obtained by the CDR collection module deployed on the HTTP traffic collection node, and is denoted as CDR data D1.

[0033] For example, the call detail record (CDR) data D1 contains complete information about HTTP requests and responses, including but not limited to: request timestamp, requester IP address, HTTP request headers (including fields such as User-Agent, Cookie, and Authorization), complete URL string, request method (GET / POST / PUT, etc.), request parameters, response status code, response body length, request time, and other core fields, ensuring that the data can fully reflect the parameter variations in the HTTP interaction process.

[0034] Meanwhile, the collected raw data is initially cleaned to remove format errors, such as empty URLs, missing request header fields, and duplicate call detail records. For example, deduplication is performed based on a combination key of request timestamp, requester IP, and URL to ensure the validity of call detail record data D1.

[0035] Next, extract the complete URL string corresponding to each HTTP request from the cleaned call detail record (CDR) data D1. For example, iterate through the Request-Line field of the request header of each CDR, and extract the string after the request method (GET / POST, etc.) and before the protocol version (HTTP / 1.1, etc.). This string is the target URL. For example, from GET http: / / example.com / api / v1 / user?userId=123 HTTP / 1.1, the URL extracted is http: / / example.com / api / v1 / user?userId=123.

[0036] Optionally, after extraction, all URLs are stored using a trie data structure. For example, the construction process of the trie is as follows:

[0037] Initialize the prefix tree with an empty string as the root node;

[0038] For each URL, process it character by character in order, starting from the root node. Check if the current character has a corresponding child node: if it does not exist, create a new node with node attributes including character value, URL count passed through the node, and whether it is a URL end marker; if it already exists, directly enter the child node.

[0039] After processing each character of the URL, increment the URL count of the current node by 1; when processing the last character of the URL, set the corresponding node's URL end flag to "yes", marking the node as the end position of a complete URL.

[0040] This storage method enables efficient prefix lookup of URLs (such as quickly counting all URLs prefixed with http: / / example.com / api / v1), while reducing redundant storage and improving the efficiency of subsequent URL field processing.

[0041] In one embodiment, for S102, URL splitting is based on preset rules. For example, based on the structural characteristics of the URL, preset splitting rules are formulated to split each URL into three sub-fields: path segment, parameter name, and parameter value. For example, the specific splitting process is as follows:

[0042] First-level splitting (separation of path segment and query parameters): For example, the URL is divided into two parts using "?" as the separator: the part before "?" is the path part, and the part after "?" is the query parameter part. If the URL does not contain "?", such as http: / / example.com / api / v1 / user, only the path part is retained, and the query parameter part is empty.

[0043] Secondary splitting (path segment splitting): For example, the path portion is split using " / " as the delimiter to obtain a sequence of path segments. For instance, the path portion http: / / example.com / api / v1 / user is split into the path segment sequence ["http:","","example.com","api","v1","user"], where "api", "v1", and "user" are the core path segments with business semantics, used for subsequent feature analysis.

[0044] The three-level splitting (query parameter key-value pair splitting) is exemplified as follows: For the query parameter part, first, it is split into multiple independent parameter name-parameter value pairs using "&" as the separator, such as "userId=123&page=1" split into ["userId=123","page=1"]; then, for each parameter name-parameter value pair, it is split into parameter name (such as "userId" "page") and parameter value (such as "123" "1") using "=" as the separator. If a parameter name-parameter value pair does not contain "=" (such as "debug"), then the parameter name is that string, and the parameter value is set to "empty".

[0045] By splitting the URL into three levels as described above, the complex URL string is transformed into a structured set of subfields, ensuring that each subfield has a clear semantic meaning, which facilitates subsequent BM25F algorithm calculations.

[0046] In this embodiment, for the calculation of subfield scores based on the BM25F algorithm, for example, for all the subfields obtained by splitting (path segment, parameter name, parameter value), the BM25F algorithm is used to calculate the relevance score of each subfield to the HTTP parameter variation awareness target. For example, the BM25F score of the subfield is calculated by the following formula:

[0047] BM25F=w×(TF×IDF) / [TF+k1×(1-b+b×L / L_avg)]

[0048] Where TF stands for Term Frequency, which represents the frequency of a certain subfield appearing in all URLs of the corresponding subfield type.

[0049] IDF stands for Inverse Document Frequency, which reflects the scarcity of a subfield in the URL set. For example, the calculation formula is IDF=log[(total number of URLs - number of URLs containing this subfield + 0.5) / (number of URLs containing this subfield + 0.5)]+1.

[0050] For example, if a certain path segment "pay" appears only in 50 URLs, and the total number of URLs is 1000, then IDF=log[(1000-50+0.5) / (50+0.5)]+1≈log(18.82)+1≈1.27+1=2.27.

[0051] w represents the field weight, indicating that different weights are assigned based on the type of the subfield. For example, the parameter name directly reflects the core parameters of the HTTP request, and its weight is set to 1.2; the path segment reflects the resource location, and its weight is set to 1.0; the parameter values ​​are highly diverse and some have no clear semantics, so their weight is set to 0.8.

[0052] k1 is a saturation parameter, which is set to 1.2 in this embodiment to control the upper limit of TF value growth and prevent a certain subfield from having an excessively high score due to its high frequency of occurrence.

[0053] b is the length normalization parameter, set to 0.75, to balance the influence of subfields of different lengths.

[0054] L field length: The number of characters in the current subfield; Average field length (L_avg): The average number of characters in all subfields of the same type.

[0055] As an example, for a parameter name "userId", TF=800, IDF=1.5, w=1.2, k1=1.2, b=0.75, L=6 ("userId" is 6 characters), L_avg=5 (the average number of characters for all parameter names is 5). Then BM25F=1.2×(800×1.5) / [800+1.2×(1-0.75+0.75×6 / 5)]≈1.2×1200 / [800+1.2×1.1]≈1440 / 801.32≈1.8.

[0056] In this embodiment, for the screening of highly relevant fields and the construction of the F1 database of fields of interest, for example, a preset BM25F score threshold (this threshold is calibrated based on historical data, initially set to 1.5, and can be dynamically adjusted according to business needs) is used to screen the BM25F scores of all sub-fields. For example,

[0057] Subfields with scores greater than or equal to a threshold are identified as highly relevant fields and included in the candidate field set.

[0058] The candidate field set is deduplicated (e.g., the parameter name "userId" that appears repeatedly in different URLs is only kept once), and the association information of the subfields is supplemented, including the subfield type (path segment / parameter name / parameter value), the URL prefix, the BM25F score, and the business semantic description (e.g., 'userId: unique user identifier').

[0059] The processed highly relevant fields are stored in a structured manner according to the above-mentioned association information, forming the focus field library F1. F1 supports dynamic updates. Each time a URL processing flow is completed, newly selected highly relevant fields are added to the library to ensure that the fields in the library can continuously cover the core features of HTTP parameter changes.

[0060] In one embodiment, for S103, the preset content recognition rule base R1 is a set of rules constructed in the early stage through business analysis and historical data verification, and for example, it includes three types of core rules:

[0061] Field compliance rules, such as defining compliance standards for the format and value range of highly relevant fields. For example, the userId field must be an 18-digit numeric string, the response status code must be any value from 200 / 201 / 400 / 401 / 404 / 500, and the token field must be a 32-character combination of uppercase and lowercase letters and numbers.

[0062] Anomaly filtering rules, for example, define the characteristics of abnormal HTTP requests that need to be excluded. For example, a single IP address making more than 1,000 requests per day is considered a malicious request; URLs containing directory traversal or injection risk characters such as ".. / " or ";" are considered abnormal requests; and request parameters with empty or non-optional values ​​are considered invalid requests.

[0063] Business-related compliance rules, for example, define the matching relationship between fields and business scenarios. For instance, when the payment interface URL prefix is ​​ / api / v1 / pay, it must include the orderId and amount parameters; the user registration interface must include the phone and verifyCode parameters.

[0064] Each rule in R1 includes attributes such as rule ID, rule type, rule description, judgment conditions, and effective status, which facilitates rule management and invocation.

[0065] In this embodiment, for example, a process of line-by-line verification, multi-rule matching, and result classification is adopted to filter based on the R1 dialog box data D1. Specifically,

[0066] Validate each record individually. For example, read each call detail record (CDR) record in the order of its collection time (D1). Execute all rules in R1 for each CDR in sequence. The validation order is based on the priority of field compliance rules → anomaly filtering rules → business-related compliance rules. If a rule with higher priority fails validation, the CDR is directly determined to be invalid, and there is no need to execute subsequent rule validations, thus improving filtering efficiency.

[0067] Multiple rules are used for matching. For example, if the "userId" field of a certain call detail record (CDR) is a 17-digit number, which does not comply with the rule that the userId field must be an 18-digit numeric string, it is directly marked as an invalid CDR, and the reason for invalidity is recorded as an incorrect userId format. If the "userId" format of a certain CDR is compliant, but the daily request frequency of a single IP address is 1200 times, triggering the abnormal filtering rule that the daily request frequency of a single IP address exceeds 1000 times, it is marked as an invalid CDR. If a certain CDR has compliant fields, no abnormal characteristics, and the payment interface URL contains the orderId and amount parameters, which comply with the business-related compliance rules, it is marked as a valid CDR.

[0068] After filtering, the valid call detail records (CDRs) are organized in a unified format. For example, the format includes the request timestamp, requester IP, URL, key-value pairs of core parameters (taken from the focus field library F1), response status code, request time, and usage duration. After being sorted in ascending order by the request timestamp, they are written to the CDR library D2 in batches.

[0069] In one embodiment, for S104, for example, based on the valid call detail records in the call detail record database D2, statistics and analysis are performed on five core data indicators: number of customers, growth rate, retention rate, customer regional distribution ratio, and average usage time per person.

[0070] Specifically, customer count statistics can be achieved by using user identifiers (such as userId or device ID) as unique keys to deduplicate daily / weekly / monthly call detail records, thus obtaining the number of customers (i.e., daily active users / weekly active users / monthly active users) within the corresponding period.

[0071] Growth rate calculation, for example, is divided into daily growth rate and weekly growth rate, and the calculation formulas are as follows:

[0072] Daily growth rate = (Number of customers today - Number of customers yesterday) / Number of customers yesterday × 100%

[0073] Weekly growth rate = (Number of customers this week - Number of customers this week) / Number of customers this week × 100%

[0074] If the number of customers was 950 the previous day and 1000 the current day, then the daily growth rate = (1000-950) / 950×100%≈5.26%.

[0075] Retention rate calculation, for example, focuses on the 7-day retention rate. The statistical logic is as follows: filter customer set A on day T, and count the number of users belonging to A in customer set B on day T+7. The 7-day retention rate = (B ∩ number of users in A / number of users in A) × 100%. For example, customer set A contains 1000 people on day T (May 1st), and customer set B contains 800 people on day T+7 (May 8th). Of these, 650 are users belonging to A. Therefore, the 7-day retention rate = 650 / 1000 × 100% = 65%.

[0076] Customer regional distribution statistics are calculated, for example, by associating the "requester IP address" in the call detail record (CDR) database D2 with a third-party geographic information database (such as IP2Location) to obtain the provincial-level administrative region (e.g., City A, Province B) corresponding to each IP address; the number of customers corresponding to each region is then counted, and the proportion of customers in each region to the total number of customers is calculated. For example, if the total number of customers is 1000, with 150 in City A and 120 in City C, the corresponding regional proportions are 15% and 12%, respectively.

[0077] Average usage time per user is calculated, for example, by calculating the time difference between the first and last request times of the day (i.e., the usage time per user per day) and summing up the usage time of all users to obtain the total usage time; Average usage time per user = Total usage time / Number of customers on that day. For example, if the total usage time is 15,000 minutes and the number of customers on that day is 1,000, then the average usage time per user is 15 minutes.

[0078] In this embodiment, the moving average smoothing method and the deviation threshold judgment method are used to detect whether there are abnormal deviations in the data indicators.

[0079] Specifically, three sliding period windows—daily, weekly, and monthly—are set up to calculate the moving average smoothed value of each data indicator under different windows:

[0080] Daily window: Take the indicator values ​​of the current day and the previous two days, for a total of 3 days, and calculate the average value as the smoothed value for the day;

[0081] Weekly window: Take the indicator values ​​of the current week and the previous week, for a total of 2 weeks, and calculate the average value as the smoothed value for the current week;

[0082] Monthly window: Take the indicator values ​​of the current month and the previous two months, for a total of three months, and calculate the average value as the smoothed value for the current month.

[0083] In this embodiment, a preset deviation threshold is set. For example, the standard deviation is calculated based on the historical 6-month indicator data, and ±2 times the standard deviation is set as the normal deviation range. The current smoothed value of each indicator is compared with the normal smoothed value of the same period in history (such as the smoothed value of the same month last year and the last 3 weeks).

[0084] If a single indicator exceeds the deviation range in a single window (e.g., the daily window smoothing value of customer numbers exceeds the normal range, but the weekly window, monthly window, and other indicators are normal), it is judged as a short-term fluctuation and there is no need to trigger an R1 update.

[0085] If at least two data metrics (such as the number of customers and the average usage time per person) exceed the normal deviation range in at least two windows (such as the daily window and the weekly window), and the duration of the deviation exceeds the preset value (the preset value is 7 days), it is judged as a long-term trend deviation, indicating that the existing R1 rules can no longer adapt to the current HTTP traffic characteristics (such as the deviation in the regional distribution ratio caused by the addition of new regional users, and the false filtering of valid call detail records caused by changes in the format of business parameters), triggering the update process of the content recognition rule base R1.

[0086] In one embodiment, triggering an update to the content recognition rule base R1 when the deviation exceeds the limit includes: inputting the input call detail record data D1 and the attention field library F1 into a pre-trained Transformer model, outputting predicted content recognition rules, and updating the content recognition rule base R1 based on the predicted content recognition rules.

[0087] Specifically, firstly, the input call detail record data D1 and the focus field library F1 input to the Transformer model are standardized to ensure that the data format meets the model input requirements, which will not be elaborated here.

[0088] In this embodiment, the Transformer model adopts an Encoder-Decoder architecture, such as... Figure 2 As shown, the specific structure of the model includes:

[0089] The encoder consists of multiple stacked Transformer blocks, each containing four parts: multi-head attention mechanism, layer normalization, feedforward neural network, and residual connection.

[0090] Specifically, regarding multi-head attention mechanisms, for example, eight parallel attention heads are set up, each head independently calculates the association weights of different features in the input data, and outputs attention features through a query (Q)-key (K)-value (V) mechanism.

[0091] Regarding feedforward neural networks, for example, a linear layer 1 → ReLU activation function → linear layer 2 structure is used to perform non-linear transformation on attention features, thereby enhancing the model's ability to express complex features;

[0092] Layer normalization and residual connections, for example, are added before and after multi-head attention mechanisms and feedforward neural networks to avoid gradient vanishing.

[0093] The decoder consists of multiple Transformer blocks with the same structure as the encoder, with an additional masked multi-head attention mechanism added before each block.

[0094] Specifically, regarding the masked multi-head attention mechanism, for example, by constructing a lower triangular mask matrix (with future position weights set to -∞), the model is shielded from accessing future position information when generating rule sequences (e.g., when generating the second rule, only the first rule is referenced, and the third to fifth rules are not obtained in advance), ensuring the order and logic of rule generation;

[0095] Regarding encoder-decoder attention mechanisms, for example, an association is established between the encoder's output features and the decoder's currently generated sequence, enabling the decoder to accurately reference the HTTP parameter features in the input data when generating rules.

[0096] The output layer, for example, is a rule-based element generation layer; exemplarily, it employs a differentiated generation strategy for different elements.

[0097] For rule types, generate category headers (field compliance / anomaly filtering / business association compliance, a total of 3 categories), and output category labels;

[0098] For core fields, select highly relevant fields from the F1 database of fields of interest through the sequence generation header, and output the specific field names (such as userId, orderId, amount).

[0099] For the judgment conditions, a structured header is generated, and different judgment logics are adapted according to the rule type. For example, the field compliance rule outputs the format requirements (e.g., 18-digit number) and value range (e.g., 10≤amount≤10000), the anomaly filtering rule outputs the threshold conditions (e.g., single IP daily request frequency ≤1000 times) and risk characteristics (e.g., URL contains .. / ), and the business-related compliance rule outputs the field association requirements (e.g., the payment interface must include orderId and amount).

[0100] For the scope of application, the specific applicable interface (such as / api / v1 / pay / *, full service interface) is output by associating the business interface information of the input call detail record data D1.

[0101] For confidence level, the output is a value between 0 and 1 based on the cumulative probability calculation of the rule generation process by the decoder (≥0.8 indicates a high confidence level rule).

[0102] Based on the above model architecture, the process of outputting predicted content recognition rules, for example, includes the following:

[0103] The input data is fed into the encoder, processed by multiple Transformer blocks, and outputs a vector matrix containing deep features of HTTP parametric data (with dimensions consistent with the input data).

[0104] The decoder generates rule elements in the order of rule type → core field → decision condition → effective scope → confidence level. When generating each element, the preceding elements and the HTTP parameter variation features output by the encoder are referenced (e.g., when generating the decision condition for "userId", the format distribution features of the userId field extracted by the encoder over the past 7 days are referenced).

[0105] The encoder output features are associated with specific judgment conditions. For example, if the encoder detects that 98% of the userId fields in the past 7 days are 18-digit numbers, the decoder generates a judgment condition that the userId value is an 18-digit number string; if it detects that 95% of the amount fields in the payment interface are between 10 and 10000, the decoder generates an amount field value range of 10 ≤ amount ≤ 10000.

[0106] As an example, the model output examples are shown in Table 1 below.

[0107] Table 1. Examples of Model Output

[0108]

[0109] Optionally, the rules output by the model can be filtered based on confidence thresholds and business rationality to obtain effective prediction rules.

[0110] In one embodiment, updating the content recognition rule base R1 based on the predicted content recognition rule includes: if the predicted content recognition rule contains a new rule not covered in R1, then adding the new rule; if the predicted content recognition rule conflicts with existing rules in R1, then replacing the old rule in R1 and retaining the new rule.

[0111] Specifically, the filtered rules are compared with the existing rules in R1. If the core field and rule type of a certain rule have no matching items in R1 (i.e., R1 does not cover the rule of this type with that field), then the addition operation is performed.

[0112] If the core fields and rule type of the specific rule are consistent with those of the existing rules in R1, but the judgment conditions are contradictory (e.g., the existing rules in R1 have a 24-bit token field, while the specific rule has a 32-bit token field), then it is determined to be a rule conflict; the old rule in R1 is replaced, and the new rule is retained.

[0113] In one embodiment, the pre-training process of the Transformer model includes:

[0114] A training dataset is constructed based on call detail record (CDR) data D1, attention field library F1, and content recognition rule library R1. Input and target sequences are constructed, with the input sequence based on CDR data D1 and attention field library F1, and the target sequence based on R1 rules. A Transformer model containing an encoder and decoder is constructed; the encoder includes a multi-head attention mechanism and a feedforward neural network, while the decoder incorporates a masked multi-head attention mechanism. Forward propagation, loss calculation, and backpropagation are performed using the cross-entropy loss function. Parameters are updated using the Adam optimizer, and iterative training is conducted to obtain the initial training model.

[0115] Specifically, the construction of the training dataset focuses on covering all HTTP parametric features and the learning objective of matching rules. It integrates three core data types: call detail record (CDR) data D1, the focus field library F1, and the content recognition rule library R1. Through preprocessing, training samples are formed. For example, CDRs containing the F1 field are selected from D1. The field attributes of F1 (such as type and compliance format) are associated with the valid rules of R1 (such as userId being an 18-digit number). The dataset is then split into training and validation sets in an 8:2 ratio to ensure that the data covers the core HTTP features and rules.

[0116] The input sequence, based on basic call detail record features (such as request interface and time) and F1 field features (such as BM25F score and compliance), is formatted as a fixed-length numerical vector, enabling the model to read key HTTP information.

[0117] The target sequence, based on specific R1 rules, includes rule type (e.g., field compliance), core field (e.g., userId), decision condition (e.g., 18-digit number), and confidence level (e.g., 0.95). Its format matches the input sequence, clearly defining the model's learning objective.

[0118] In the forward propagation, after the input sequence is processed by the encoder to extract features, the decoder gradually generates the prediction rule sequence.

[0119] Loss is calculated using the cross-entropy loss function, comparing the deviation between the predicted sequence and the target sequence (R1 rule). The smaller the loss value, the more accurate the prediction.

[0120] Backpropagation starts from the loss value and calculates the gradients of all model parameters (such as attention weights) in reverse to clarify the direction of parameter adjustment.

[0121] For parameter updates, the Adam optimizer is used, which combines gradients to dynamically adjust parameters and reduce loss.

[0122] In one embodiment, based on the content recognition rules output by the initial training model, call detail record (CDR) data D1 is filtered to form a model CDR library D3; model CDRs in the model CDR library D3 and CDRs in the CDR library D2 within the same date range are selected, and their deviations are compared in multiple dimensions; if the deviation in any dimension is greater than a preset threshold, the Transformer model is retrained based on the optimized parameters until the deviation in any dimension is less than the preset threshold, and the current Transformer model is used as a pre-trained Transformer model.

[0123] Specifically, the same filtering logic as step S103 (filtering D1 based on R1 to obtain D2) is adopted. The rules output by the initial model are used to verify the original call detail record data D1 one by one, retaining the valid call detail records that meet all the rules and removing the abnormal call detail records that do not meet the rules, forming the model call detail record library D3, ensuring that the field format and data dimensions of D3 are completely consistent with those of the call detail record library D2.

[0124] For example, the next 7 days after the data used for the initial model training are selected as a unified date interval to ensure data independence and timeliness. Call detail records (CDRs) for this interval are extracted from D3 and D2.

[0125] For example, based on the consistency of call detail record (CDR) filtering effects, four core dimensions are selected to compare D3 and D2, with a preset deviation threshold of 10% for each dimension (which can be adjusted according to business precision). Specifically, the core dimensions include:

[0126] For the absolute number of customers, count the number of unique customers (using userId as the unique key) for D3 and D2 within the interval respectively, and calculate the deviation rate = |number of customers in D3 - number of customers in D2| / number of customers in D2 × 100%. For example, if the number of customers in D2 is 7000 and the number of customers in D3 is 6500, the deviation rate is ≈7.1% (<10%), which meets the requirements.

[0127] The customer regional distribution ratio is calculated by statistically analyzing the percentage of customers in each province and determining the corresponding regional percentage deviation = |D3 region percentage - D2 region percentage|. For example, if City A accounts for 15% in D2 and 14.2% in D3, the deviation is 0.8% (<10%), which meets the requirements.

[0128] For average usage time per user, calculate the total usage time for both D3 and D2 periods divided by the total number of customers. The deviation rate is calculated as: |Average usage time per user in D3 - Average usage time per user in D2| / Average usage time per user in D2 × 100%. For example, if the average usage time per user in D2 is 15 minutes and in D3 it is 14.1 minutes, the deviation rate is 6% (<10%), which meets the requirements.

[0129] The effective call detail record (CDR) service matching degree is calculated by comparing the percentage of effective CDRs in D3 and D2 corresponding to core business interfaces (such as payment and registration interfaces). The deviation rate is calculated as |D3 service percentage - D2 service percentage| × 100%. For example, if the payment interface CDR percentage in D2 is 30% and in D3 it is 28.5%, the deviation is 1.5% (<10%), which meets the requirements.

[0130] In this embodiment, if the deviation between D3 and D2 in any dimension is greater than the preset threshold (such as a customer number deviation rate of 12% or a regional proportion deviation of 11%), it indicates that there is a deviation in the initial model output rules (such as missing some valid call records or misjudging the regional affiliation), and optimization training is started.

[0131] Specifically, the optimization includes supplementing sample data related to the deviation dimension. For example, for deviations in the number of customers, add call detail records (CDRs) with abnormal / compliant user identifier formats; for deviations in the number of customers, add CDRs from different IP regions to ensure that the training data covers deviation scenarios.

[0132] Adjust the Adam optimizer learning rate (e.g., reduce it from 0.001 to 0.0005 to avoid parameter oscillations), increase the number of training epochs (e.g., increase it from 10 epochs to 15 epochs), and adjust the batch size (e.g., increase it from 32 to 64 to improve the stability of feature learning).

[0133] Repeat the training process (forward propagation to generate rules → cross-entropy loss calculation → backpropagation to calculate gradients → Adam to update parameters) using the optimized dataset and parameters to obtain the optimized model.

[0134] The optimized model is used again to output rules → filter D1 to get new D3 → compare the deviation with D2. If the deviation of all dimensions is less than the preset threshold, it means that the model performance meets the standard, and the current model is set as the pre-trained Transformer model. If the deviation of dimensions still exceeds the limit, repeat the steps of parameter adjustment-retraining-deviation comparison until the deviation of all dimensions meets the requirements, so as to ensure that the pre-trained model can stably generate effective rules with the same filtering effect as R1.

[0135] Figure 3 An HTTP intelligent parameter sensing and directional matching device 300 is shown. This device embodiment is similar to... Figure 1 Corresponding to the illustrated method embodiments, this device can be specifically applied to various electronic devices. Specifically, it includes:

[0136] The call detail record (CDR) data acquisition module 301 is used to acquire input CDR data D1, extract the corresponding URL, and store it using a prefix tree.

[0137] The attention field library creation module 302 is used to split the URL into multiple sub-fields based on preset rules, calculate the score of each sub-field based on the BM25F algorithm, and store the highly relevant fields into the attention field library F1, wherein the sub-fields include path segments, parameter names, and parameter values.

[0138] The call detail record (CDR) database generation module 303 is used to filter CDR data D1 based on a preset content recognition rule base R1 and retain valid CDRs to form a CDR database D2.

[0139] The rule base update module 304 is used for data statistics and analysis of the dialogue single library D2, to detect deviations in data indicators, and to trigger an update of the content recognition rule base R1 when the deviation exceeds the limit. The data indicators mentioned include at least: number of customers, growth rate, retention rate, customer regional distribution ratio, and average usage time per person.

[0140] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to 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 methods and / or technical solutions of the foregoing embodiments of this application.

[0141] Figure 4The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 402 or a program loaded from a storage portion 408 into a random access memory (RAM) 403. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0142] The following components are connected to I / O interface 405: input section 406 including keyboard, mouse, touch screen, microphone, infrared sensor, etc.; output section 407 including cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; storage section 408 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and communication section 409 including network interface card such as LAN (local area network) card, modem, etc. Communication section 409 performs communication processing via a network such as the Internet.

[0143] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 401, it performs the functions defined in the methods of this application.

[0144] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0145] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application.

[0146] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A method for HTTP intelligent parameter change perception and targeted matching, characterized in that, Includes the following steps: Get the input call detail record data D1, extract the corresponding URL and store it using a prefix tree; The URL is split into multiple subfields based on preset rules, and the score of each subfield is calculated based on the BM25F algorithm. The highly relevant fields are then stored in the attention field library F1 in a structured manner according to the subfield association information. The subfield association information includes the subfield type, the URL prefix, the BM25F score, and the business semantic description. The subfield type includes path segment, parameter name, and parameter value. Based on the preset content recognition rule base R1, filter call detail record data D1, and retain valid call detail records to form call detail record base D2; The dialog box D2 performs data statistics and analysis, detects deviations in data indicators, and triggers an update to the content recognition rule base R1 when the deviation exceeds the limit. The data indicators mentioned include at least: number of customers, growth rate, retention rate, customer regional distribution ratio, and average usage time per person. The step of triggering an update to the content recognition rule base R1 when the deviation exceeds the limit includes using a moving average smoothing method to detect data indicators in daily, weekly, and monthly windows. If multiple data indicators deviate from the prediction results and the duration exceeds a preset value, an update to the content recognition rule base R1 is triggered. The step of triggering an update to the content recognition rule base R1 when the deviation exceeds the limit also includes: Input the input call detail record data D1 and the attention field library F1 into the pre-trained Transformer model, output the predicted content recognition rule, and update the content recognition rule library R1 based on the predicted content recognition rule; The model architecture includes an output layer, specifically a rule-based element generation layer, which employs differentiated generation strategies for different elements. For rule types, category labels are generated using a category header and output. For core fields, the sequence generation header selects highly relevant fields from the F1 database of fields of interest, and outputs the specific field names. The decision criteria are generated using a structured header, and different decision logics are adapted according to the rule type. Regarding the scope of effect, the specific effective interface is output by associating the service interface information of the input call detail record (CDR) data D1. For the confidence level, the output is a value between 0 and 1, calculated based on the cumulative probability of the rule generation process by the decoder. Based on the above model architecture, the process of outputting predicted content recognition rules includes, The input data is fed into the encoder, processed by multiple Transformer blocks, and outputs a vector matrix containing deep features of HTTP parametric variables. The decoder generates rule elements in the order of rule type, core fields, decision conditions, scope of application, and confidence level. Each element is generated with reference to the preceding elements and the HTTP parameter features output by the encoder. The features output by the encoder are associated with specific judgment conditions, and the rules output by the model are filtered based on the confidence threshold and business rationality to obtain effective prediction rules. F1 supports dynamic updates. Each time a URL processing cycle is completed, newly selected highly relevant fields are added to the database to ensure that the fields in the database can continuously cover the core features of HTTP parameter changes.

2. The HTTP intelligent parameter variation perception and targeted matching method according to claim 1, characterized in that, It also includes, The pre-training process of the Transformer model includes: A training dataset is constructed based on call detail record data D1, attention field library F1, and content recognition rule library R1. The input sequence and target sequence are constructed. The input sequence is constructed based on call detail record data D1 and attention field library F1, and the target sequence is constructed based on R1 rules. A Transformer model with encoder and decoder is constructed. The encoder includes a multi-head attention mechanism and a feedforward neural network, and the decoder adds a masked multi-head attention mechanism. The cross-entropy loss function is used for forward propagation, loss calculation and backpropagation. The parameters are updated based on Adam optimizer and iterative training is performed to obtain the initial training model.

3. The HTTP intelligent parameter variation perception and targeted matching method according to claim 2, characterized in that, Also includes: Based on the content recognition rules output by the initial training model, the call detail record (CDR) data D1 is filtered to form the model CDR library D3. Select model call detail records (CDRs) from the model call detail record (CDR) library D3 and the CDRs from the CDR library D2 within the same date range, and compare their deviations in multiple dimensions. If the deviation in any dimension is greater than a preset threshold, retrain the Transformer model based on the optimized parameters until the deviation in any dimension is less than the preset threshold, and use the current Transformer model as the pre-trained Transformer model.

4. The HTTP intelligent parameter variation perception and targeted matching method according to claim 1, characterized in that, The step of updating the content recognition rule base R1 based on the predicted content recognition rule includes: if the predicted content recognition rule contains a new rule not covered in R1, then the new rule is added; if the predicted content recognition rule conflicts with existing rules in R1, then the old rule in R1 is replaced and the new rule is retained.

5. An HTTP intelligent parameter change sensing and directional matching device, characterized in that, include: The call detail record (CDR) data acquisition module is used to acquire input CDR data D1, extract the corresponding URL, and store it using a prefix tree. The focus field library creation module is used to split the URL into multiple subfields based on preset rules, calculate the score of each subfield based on the BM25F algorithm, and store the highly relevant fields into the focus field library F1 in a structured manner according to the subfield association information. The subfield association information includes the subfield type, the URL prefix, the BM25F score, and the business semantic description. The subfield type includes path segment, parameter name, and parameter value. The call detail record (CDR) database generation module is used to filter CDR data D1 based on a preset content recognition rule base R1 and retain valid CDRs to form a CDR database D2. The rule base update module is used for data statistics and analysis of the dialogue single library D2, to detect deviations in data indicators, and to trigger an update of the content recognition rule base R1 when the deviation exceeds the limit. The data indicators mentioned include at least: number of customers, growth rate, retention rate, customer regional distribution ratio, and average usage time per person. The step of triggering an update to the content recognition rule base R1 when the deviation exceeds the limit includes using a moving average smoothing method to detect data indicators in daily, weekly, and monthly windows. If multiple data indicators deviate from the prediction results and the duration exceeds a preset value, an update to the content recognition rule base R1 is triggered. The step of triggering an update to the content recognition rule base R1 when the deviation exceeds the limit also includes: The input call detail record (CDR) data D1 and the attention field library F1 are input into a pre-trained Transformer model, which outputs a predicted content recognition rule. The content recognition rule library R1 is then updated based on the predicted content recognition rule. The model architecture includes an output layer, specifically a rule-based element generation layer, which employs differentiated generation strategies for different elements. For rule types, category labels are generated using a category header and output. For core fields, the sequence generation header selects highly relevant fields from the F1 database of fields of interest, and outputs the specific field names. The decision criteria are generated using a structured header, and different decision logics are adapted according to the rule type. Regarding the scope of effect, the specific effective interface is output by associating the service interface information of the input call detail record (CDR) data D1. For the confidence level, the output is a value between 0 and 1, calculated based on the cumulative probability of the rule generation process by the decoder. Based on the above model architecture, the process of outputting predicted content recognition rules includes, The input data is fed into the encoder, processed by multiple Transformer blocks, and outputs a vector matrix containing deep features of HTTP parametric variables. The decoder generates rule elements in the order of rule type, core fields, decision conditions, scope of application, and confidence level. Each element is generated with reference to the preceding elements and the HTTP parameter features output by the encoder. The features output by the encoder are associated with specific judgment conditions, and the rules output by the model are filtered based on the confidence threshold and business rationality to obtain effective prediction rules. F1 supports dynamic updates. Each time a URL processing cycle is completed, newly selected highly relevant fields are added to the database to ensure that the fields in the database can continuously cover the core features of HTTP parameter changes.

6. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the processor; wherein, The memory stores instructions that can be executed by the processor to enable the processor to perform the method of any one of claims 1-4.

7. A computer-readable medium having computer program instructions stored thereon, characterized in that, The computer program instructions can be executed by a processor to implement the method as described in any one of claims 1-4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-4.

Images