Dynamic privacy budget analysis method and device, medium and program product

Abstract

The invention discloses a dynamic privacy budget analysis method and device, a medium and a program product, and relates to the field of data security and privacy computing. The size of a query influence domain is estimated through a database query optimizer, and when it is found that the number of estimated data records is lower than an individual recognition threshold value, high-risk query is recognized. For such queries, the privacy leakage risk caused by repeated query behaviors of the user is quantified by further calculating the overlapping degree of the current query influence domain and the historical influence domain in the scheme. A budget attenuation factor which is generated based on the overlapping degree and is inversely proportional to the overlapping degree can dynamically adjust the privacy budget: the higher the overlapping degree is, the higher the risk is, and the more the budget attenuation is. Finally, the budget value subjected to dynamic attenuation is combined with the user permission and the data sensitivity to jointly determine the magnitude of the differential privacy noise. The technical effect that the accuracy of privacy protection is improved while the data availability is guaranteed is achieved.

Description

Technical Field

[0001] This application relates to the field of data security and privacy computing, and in particular to a dynamic privacy budget analysis method, device, medium, and program product. Background Technology

[0002] In the field of medical data analytics, hospitals and research institutions need to conduct large-scale statistical analyses of electronic health records (EHRs) to support clinical research and public health decision-making, while strictly adhering to medical privacy regulations such as HIPAA. Differential privacy technology, by adding calibration noise to query results to prevent the leakage of individual patient information, has become a mainstream technology for privacy protection in medical data analytics.

[0003] In related technologies, differential privacy technology can employ a dynamic privacy budget allocation mechanism. By establishing a time-series allocation model for the privacy budget, the corresponding privacy budget value is dynamically calculated for each query based on the time sequence of queries and historical query patterns. The system maintains a global budget pool. When the i-th query is received, the budget amount εᵢ to be allocated to this query is calculated according to a preset mathematical function (such as a Poisson distribution or an exponential decay function). Then, the corresponding value is deducted from the global budget pool, and the noise intensity to be added to the query results is determined based on this budget value.

[0004] However, due to the large number of rare diseases and special cases in medical data, in related technologies, when researchers construct combinations of conditions corresponding to rare diseases or special cases in medical data, although the query is still statistical in syntax, it may actually match very few patient records during execution. Related technologies still allocate budgets and noise intensity according to low-risk standards, leading to a mismatch between the privacy protection budget and the actual impact on the data, thus reducing the reliability of privacy protection. Summary of the Invention

[0005] This application provides a dynamic privacy budget analysis method, device, medium, and program product for improving the reliability of privacy protection.

[0006] In a first aspect, the application provides a dynamic privacy budget analysis method applied to a device, the method comprising: after receiving a target query request sent by a user terminal, calculating an estimated number of data records matching a query condition parameter by calling a database query optimizer, and determining the estimated number of data records and its corresponding data record set as a query impact domain, the query request containing a user identity, a query statement and a query condition parameter; when the estimated number of data records is lower than a preset individual identification threshold, determining an average ratio of the query impact domain to a historical impact domain as a data record overlap degree based on historical query records of the user terminal, the historical query records including historical impact domains corresponding to previous queries of the user terminal within a preset time window; generating a budget decay factor based on the data record overlap degree, the budget decay factor being a positive number less than or equal to 1 and inversely proportional to the data record overlap degree; obtaining a sensitivity multiplier of a data field involved in the query statement and a permission base budget value corresponding to the user identity, and then multiplying the permission base budget value, the sensitivity multiplier and the budget decay factor to obtain a final privacy budget value; calling a differential privacy algorithm based on the final privacy budget value to add calibration noise to a query result, generating a privacy-protected query result and returning it to the user terminal.

[0007] By using the above technical solution, the size of the query impact domain is estimated by the database query optimizer, and when it is found that the estimated number of data records is lower than the individual identification threshold, a high-risk query is identified. For such queries, the scheme further quantifies the privacy leakage risk caused by repeated query behavior of the user by calculating the overlap degree of the current query impact domain and the historical impact domain. The budget decay factor generated based on the overlap degree is inversely proportional to the overlap degree, which can dynamically adjust the privacy budget: the higher the overlap degree, the greater the risk, and the more the budget decays. Finally, this dynamically decayed budget value is combined with the user's permissions and data sensitivity to determine the size of the differential privacy noise. This effectively solves the problem of fixed budget allocation in the prior art, which cannot cope with repeated query attacks, and achieves the technical effect of improving the accuracy and robustness of privacy protection while ensuring data usability.

[0008] In some embodiments of the first aspect, in some embodiments, the average ratio of the query influence domain and the historical influence domain is determined as a data record overlap degree based on the historical query records of the user terminal by calculating a ratio of an intersection and a union of the query influence domain and the historical influence domain, specifically comprising: constructing a time decay weight sequence according to the query time sequence of the historical query, the weight value corresponding to the historical query record closer to the current query time in the time decay weight sequence is larger; traversing the data record identifier set in the historical influence domain, performing set operation on the data record identifier set in the query influence domain and the data record identifier set in the historical influence domain, obtaining the intersection record quantity and the union record quantity corresponding to the historical influence domain; dividing the intersection record quantity corresponding to the historical influence domain by the corresponding union record quantity to obtain a single overlap ratio; based on the time decay weight sequence, multiplying the single overlap ratio corresponding to the historical query and the corresponding time decay weight to obtain a weighted overlap ratio, the time decay weight is inversely proportional to the time interval; performing arithmetic average operation on all the weighted overlap ratios to obtain the data record overlap degree.

[0009] By adopting the above technical solution, when calculating the data record overlap degree, the concept of time decay weight is introduced. By constructing a time decay weight sequence for historical query records, the query records closer to the current time have a larger proportion in the overlap degree calculation. After multiplying the single overlap ratio and the time decay weight, the weighted overlap ratio can more accurately reflect the relevance of the current query and the user's recent exploration behavior, rather than simply averaging all historical behaviors. The overall data record overlap degree obtained by arithmetic average can therefore more accurately depict the immediate privacy risk caused by continuous and concentrated query behavior. This effectively solves the risk assessment distortion problem caused by treating long-term and short-term queries equally in traditional overlap degree calculation, realizes more sensitive capture of user query intent and more timely response to potential attacks, and improves the timeliness and accuracy of risk quantification.

[0010] In some embodiments of the first aspect, in the step of multiplying the permission-based budget value, the sensitivity multiplier and the budget decay factor to obtain the final privacy budget value, when the estimated number of data records is lower than the preset individual identification threshold, the method comprises: converting the query condition parameters in the target query request and the query condition parameters of the historical queries in the historical query records into query condition semantic vectors to obtain a current query condition semantic vector of the current query and a plurality of historical query condition semantic vectors of the historical queries; identifying the historical queries that form a continuous query sequence with the current query condition semantic vector by calculating the vector cosine similarity between the current query condition semantic vector and the plurality of historical query condition semantic vectors, the continuous query sequence being a group of time-sequentially continuous queries with a semantic similarity higher than a preset similarity threshold within the preset time window; determining a query intent convergence risk coefficient based on the length of the continuous query sequence and the average similarity of all query condition semantic vectors in the sequence, the query intent convergence risk coefficient being directly proportional to both the length and the average similarity of the sequence; multiplying the permission-based budget value, the sensitivity multiplier and the budget decay factor, and dividing the product obtained by the query intent convergence risk coefficient to obtain the final privacy budget value.

[0011] By adopting the above technical solution, the method converts the query condition parameters into semantic vectors, so as to compare the similarity of queries at the semantic level rather than the simple string level. By calculating the vector cosine similarity, the system can identify a “continuous query sequence” in which a user gradually narrows down the target range through a series of queries with different wording but similar intent. The query intent convergence risk coefficient determined based on the length and average similarity of the sequence accurately quantifies the risk of this advanced attack mode. Finally, by dividing the regular calculated privacy budget by this risk coefficient, an additional and targeted budget reduction is achieved. This series of processes enables the system to capture the intent behind user queries, effectively solves the problem that the prior art cannot prevent semantic-level progressive attacks (differential attacks), realizes the defense against hidden privacy probing behavior, and enhances the intelligence and foresight of the privacy protection system.

[0012] In some embodiments of the first aspect, before the step of multiplying the permission-based budget value, the sensitivity multiplier and the budget decay factor to obtain the final privacy budget value, the method further comprises: querying the global frequency of the data field involved in the pre-constructed sensitive numerical value dictionary; generating a numerical rarity decay factor inversely proportional to the global frequency based on the global frequency; and selecting the smaller one of the budget decay factor and the numerical rarity decay factor as the updated budget decay factor.

[0013] By adopting the technical scheme, the method introduces consideration of the rarity of the query value itself. By querying the global frequency in the pre-constructed sensitive numerical value dictionary and generating a numerical rarity decay factor inversely proportional to the frequency, the scheme can identify queries for rare numerical values. Since queries for rare attribute values are a common means of targeting specific individuals, such queries inherently involve higher privacy risks. By selecting the smaller of the budget decay factor and the numerical rarity decay factor as the final decay factor, the scheme ensures that the privacy budget is more strictly limited when either the behavior pattern risk (high overlap) or the data content risk (high rarity) exists. The identification and prevention of attacks using data rarity are achieved.

[0014] In combination with some embodiments of the first aspect, in some embodiments, the step of generating, based on the global frequency, a numerical rarity decay factor inversely proportional to the global frequency specifically comprises: separating non-sensitive query conditions constituting a condition context from the query condition parameters; determining a condition frequency of the sensitive numerical value in a sub-data set satisfying the condition context based on the non-sensitive query conditions; judging whether the condition frequency is lower than a preset frequency threshold and whether a ratio of the condition frequency to the global frequency is lower than a preset drift threshold; if the judgment result is yes, generating, based on the condition frequency, a numerical rarity decay factor inversely proportional to the condition frequency; and if the judgment result is no, generating, based on the global frequency, a numerical rarity decay factor inversely proportional to the global frequency.

[0015] By adopting the technical scheme, in the evaluation of numerical rarity, the method further introduces analysis of “condition frequency”, i.e., taking the non-sensitive conditions of the query as a context. By judging whether the condition frequency of the sensitive numerical value in a specific context is significantly lower than its global frequency (i.e., “drift”), the system can find numerical values that become exceptionally rare in a specific sub-set. The risk of queries in this case is much higher than that of globally rare queries. When detecting such high-risk “conditional rarity”, the scheme generates a smaller numerical rarity decay factor based on the lower condition frequency, thereby imposing a more severe budget penalty. The method solves the privacy risk points exposed under specific conditions that cannot be found by simple global frequency analysis, achieves fine identification of complex, multi-condition combination query attacks, and improves the depth and accuracy of risk assessment.

[0016] In some embodiments of the first aspect, in some embodiments, the step of converting the query condition parameter into a query condition semantic vector specifically comprises: decomposing the query condition parameter into one or more independent condition clauses, the condition clause containing a field name, an operator and a numerical value; finding and mapping the field name and the operator into corresponding encoding values in a preset encoding table to obtain field encoding values and operator encoding values; constructing a condition clause vector from the field encoding values and the operator encoding values corresponding to the condition clause; and splicing all the condition clause vectors in a preset order to form the query condition semantic vector.

[0017] By adopting the above technical solution, the method provides a structured and interpretable query condition semantic vector construction method. By decomposing the complex query condition parameter into independent "field name-operator-numerical value" clauses and mapping the field name and the operator into fixed encoding values, the scheme converts natural language and SQL syntax into a standardized numerical vector. This conversion not only preserves the core semantic structure of the query (which field, what comparison), but also ensures the structural consistency of the vector through the splicing order, ensuring the stability and effectiveness of the entire risk assessment system.

[0018] In some embodiments of the first aspect, in some embodiments, after receiving the target query request sent by the user terminal, the method further comprises: identifying the user corresponding to the user identity, the collaborative user identity belonging to the same preset collaboration group to form a collaboration group member set; aggregating the collaborative history query records of the collaboration group member set within the preset time window and extracting the corresponding historical influence domain in the collaborative history query records to build a collaboration group shared historical influence domain; and determining the collaboration group shared historical influence domain as part of the historical influence domain.

[0019] By adopting the above technical solution, the method extends the privacy risk assessment range from a single user to the entire collaboration group. By identifying the collaboration group to which the user belongs and aggregating the query history of all members within the group within the preset time window, a "collaboration group shared historical influence domain" is constructed. When calculating the data record overlap degree, this shared history representing the collective wisdom and common goal of the team is considered as part of the historical influence domain. This process allows the system to not only consider the user's own behavior when assessing the risk of the current query, but also consider the relevance of the user's behavior to the team's overall behavior. This achieves effective identification and quantification of potential collusion risks in team collaboration scenarios, allowing the privacy protection system to adapt to the collaboration characteristics of modern data analysis and improving overall security.

[0020] In some embodiments combining the first aspect, in some embodiments, the device comprises: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is configured to store computer program codes, the computer program codes comprise computer instructions, the one or more processors invoke the computer instructions to enable the device to perform the method of any one of claims 1-7.

[0021] In a second aspect, the present application provides a computer program product comprising instructions which, when the computer program product runs on a device, enable the device to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0022] In a third aspect, the present application provides a computer-readable storage medium comprising instructions which, when the instructions run on a device, enable the device to perform the method described in the first aspect and any possible implementation manner of the first aspect. The one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. Since the technical means of generating a budget decay factor based on the overlap degree of the query influence domain and the historical influence domain after identifying a high-risk query, and combining user permissions and data sensitivity to comprehensively calculate the final privacy budget is adopted, the method can adaptively adjust the privacy protection strategy according to the specific risk of each query (especially the repeated query risk). This process realizes the technical effect of improving the precision of privacy protection while ensuring data availability.

[0023] 2. Since the technical means of converting the query condition into a semantic vector, identifying the semantic continuous query sequence by calculating the similarity, and generating a query intention convergence risk coefficient based on the sequence characteristics to punishively reduce the privacy budget is adopted, the method can deeply understand and quantify the advanced attack behavior of the user gradually narrowing the target range through a series of different but similar intention queries. This process effectively solves the technical problem that the prior art is difficult to prevent semantic level progressive attacks (difference attacks), and further realizes the technical effect of defending against hidden privacy detection behavior, enhancing the intelligence and foresight of the privacy protection system.

[0024] 3. By employing techniques that identify the collaborative groups to which users belong, aggregate the query history of group members to construct a shared historical influence domain for the collaborative group, and use this as a key component in calculating data record overlap, this method expands the scope of privacy risk assessment from isolated individuals to collaborative groups with common goals. This process effectively solves the technical problem of existing technologies that only focus on individual users while ignoring the risk of collusion attacks caused by collaborative queries among multiple users. It thus achieves effective identification and quantification of potential collusion risks in team collaboration scenarios, enabling the privacy protection system to adapt to the collaborative characteristics of modern data analysis and improving overall security. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a dynamic privacy budget analysis method in an embodiment of this application; Figure 2 This is another flowchart illustrating a dynamic privacy budget analysis method in the embodiments of this application; Figure 3 This is a schematic diagram of an exemplary hardware structure of the device in the embodiments of this application. Detailed Implementation

[0026] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0028] Please see Figure 1 This is a flowchart illustrating a dynamic privacy budget analysis method in an embodiment of this application.

[0029] S101. After receiving the target query request sent by the user terminal, the database query optimizer is called to calculate the estimated number of data records that match the query condition parameters, and the estimated number of data records and the corresponding set of data records are determined as the query influence domain.

[0030] Wherein, the user terminal represents a client device that initiates a data query request, such as a computer workstation used by a data analyst or researcher; the target query request refers to a data packet issued by the user terminal, containing a specific query intent, usually composed of a user identity, a query statement, and a series of query condition parameters; the database query optimizer is a core component of the database management system (DBMS), its main function is to analyze the query statement based on the internal statistical information of the database (such as data distribution histogram, index base, etc.) without actually executing the query, and generate the optimal execution plan, while being able to estimate the number of rows returned by the query; the query condition parameter refers to the specific numerical or string value used to filter data in the WHERE clause of the query statement, such as "age > 65" or "city = 'Beijing'"; the estimated number of data records is a value returned by the database query optimizer, which represents the approximate total number of data records that meet the query condition parameters.

[0031] When the device receives a target query request from the user terminal at its network interface, it first parses the request and extracts the query statement and query condition parameters. Based on the query condition parameters, the device constructs a request for estimating the number of records only and passes it to the query optimizer component in the database management system. Upon receiving this request, the query optimizer uses its internal maintained data statistics to intelligently infer how many records meet these query condition parameters without performing a full table scan or traversing the index. This inference process is extremely fast, for example, if the query condition is "age > 65", the optimizer can query its pre-stored age field distribution histogram to quickly calculate the proportion of people over 65 years old, and then multiply the total number of records to obtain an estimated value. After receiving the returned estimated number of data records, the device logically defines the impact boundary of this query, that is, all records that meet the conditions constitute a "data record set". Finally, the device defines the "query impact domain" of this query as the combination of the estimated number and the logically defined record set, and passes it to the subsequent step for risk assessment.

[0032] In some embodiments, the determination of the estimated number of data records and its corresponding data record set as the query impact domain can be achieved in various ways. Optionally, the device first invokes the query optimizer to obtain the estimated number of data records, in which case the "data record set" only exists as a logical concept and is not instantiated in memory. Then, only when the subsequent step (e.g., S102) confirms that the estimated number is below the threshold, and the set operation is indeed needed, the device performs an additional, controlled operation to obtain a compact representation of the set. For example, it makes a request to a database or data service that is pre-loaded with advanced indexes (e.g., bitmap index or Roaring Bitmap index), which is capable of quickly generating a Bloom filter or bitmap representing the data record set according to the query condition, instead of returning the real ID list. In this way, both the set representation for risk assessment and the overhead of transmitting and processing large-scale raw data are avoided. Optionally, a query plan analysis approach can also be used. In this approach, the device invokes the query optimizer and requests to return a detailed execution plan. The device then parses the execution plan, which contains not only the cardinality estimation of the final result set (i.e., the estimated number of data records), but also the access path, used indexes, and cardinality information of intermediate steps. Based on this information, the device can construct a proxy object or metadata structure that represents the data record set without directly touching the data, which is sufficient to support the subsequent risk assessment. It can be understood that other ways can also be used to implement this step, which are not limited here.

[0033] It should be noted that this step does not perform an actual data query.

[0034] In some embodiments, when the device obtains an estimated number of data records from the query optimizer, especially when the value is in a "fuzzy area" near the preset individual identification threshold (e.g., within 50% to 200% of the threshold), it will start a quick verification program. The program will perform a query based on a random sampling block of the database for the target query, for example, running the query on only 1% of the data blocks. Since the data volume of the query is very small, this operation will be completed quickly. Then, the device will scale up the result number obtained by the sampling query (e.g., multiply by 100) to obtain a calibrated estimation value based on sampling. Finally, the device compares the calibrated estimation value with the original estimation value of the optimizer, and if the difference exceeds a preset tolerance (e.g., 20%), the device will adopt the more reliable calibrated estimation value as the final "estimated number of data records" and use this value to determine whether to start the subsequent risk assessment step.

[0035] In some embodiments, the device first retrieves all the historical query records of the user within a preset time window from the storage according to the user identity in the target query request, and constructs a time decay weight sequence for these historical query records in chronological order of query time, in which the closer the historical query record is to the current query time, the greater its corresponding weight value is. Then, the device traverses the data record identifier set in each historical influence domain based on the data record identifier set in the current query influence domain, and performs set operations respectively to obtain the intersection record quantity and the union record quantity corresponding to each historical influence domain. Subsequently, the device divides the intersection record quantity corresponding to each historical influence domain by the union record quantity corresponding thereto, thereby obtaining a single overlap ratio reflecting the single query association strength. The device further performs multiplication operation on the single overlap ratio and the time decay weight corresponding thereto calculated in the foregoing, to obtain a weighted overlap ratio, wherein the time decay weight is inversely proportional to the interval between the query time point and the current time. Finally, the device performs arithmetic average operation on the weighted overlap ratios calculated for all the historical queries, to obtain the data record overlap degree.

[0036] S102, when the estimated data record quantity is lower than the preset individual identification threshold, determining the average ratio of the query influence domain and the historical influence domain as the data record overlap degree based on the historical query records of the user terminal by calculating the ratio of the intersection and the union of the query influence domain and the historical influence domain.

[0037] When the device finds that the estimated data record quantity is lower than the preset individual identification threshold, it means that the current query may touch a small data range, and there is a risk of inferring individual sensitive information through multiple query combinations. At this time, the device will start a more in-depth risk assessment process. First, the device will retrieve all the historical query records associated with the current user identity from the storage system, which contain detailed information of each query performed by the user within a preset time window (e.g. the past 30 days), especially the historical influence domain corresponding to each query. Then, the device will perform set operation on each historical influence domain and the influence domain of the current query to calculate their intersection size and union size. The intersection size reflects the number of data records involved in both queries, while the union size reflects the total data range after combining the two queries. Subsequently, the device obtains a ratio between 0 and 1 by dividing the intersection size by the union size. The device calculates such a ratio for each historical influence domain, and then determines the average of all these ratios as the data record overlap degree.

[0038] In some embodiments, the intersection-union set computation of the query influence domain and the historical influence domain to determine the data record overlap ratio can be implemented in various ways. Optionally, instead of storing and processing the full set of data record identifiers directly, the device generates a compact probabilistic data structure representation, such as a Bloom Filter, for each query influence domain. When a new query influence domain is determined, the device maps the unique identifier of each data record in the influence domain to a bit array through multiple hash functions, forming the Bloom Filter representation of the influence domain. The historical influence domains are also stored as Bloom Filters in the same way. When the intersection and union need to be computed, the device can directly perform bit operations on the two Bloom Filters - the bitwise AND operation approximates the intersection, and the bitwise OR operation approximates the union. By counting the number of bits set to 1 in the resulting filter, the size of the intersection and union can be estimated, and thus the overlap ratio can be computed. Optionally, a database built-in function based implementation can also be used. In this implementation, the device delegates the set operation of the query influence domain and the historical influence domains to the database system directly. Specifically, the device constructs special SQL queries to utilize the set operators (such as INTERSECT, UNION) or window functions of the database to directly compute the intersection size and the union size. Optionally, when the data set is extremely large, the device does not process the full data, but randomly samples a certain proportion (such as 1%) of the data from the query influence domain and the historical influence domains. Then, the device only performs the intersection-union set computation on these samples, and scales up the sample results to the full set estimation based on statistical principles. It can be understood that other ways of implementing the intersection-union set computation can also be used, which are not limited here.

[0039] S103、Based on the data record overlap ratio, a budget decay factor is generated.

[0040] When the device obtains the data record overlap ratio, the device applies a pre-set conversion function to map the data record overlap ratio to a budget decay factor.

[0041] In some embodiments, the budget decay factor can be generated based on the data record overlap in various ways. Optionally, the conversion function is generally a monotonically decreasing function, i.e., the higher the overlap, the smaller the generated budget decay factor. For example, the device can use a function of the form f(x) = (1 - x)α, where x is the data record overlap, and a is a coefficient greater than 0, used to control the steepness of the decay. When the overlap is 0, it means the current query is completely disjoint from the historical queries, and the budget decay factor is 1, with no reduction. When the overlap is close to 1, it means the current query almost completely repeats the historical queries, and the budget decay factor is close to 0, meaning the available privacy budget will be greatly reduced. In this way, the device converts the qualitative risk judgment (query overlap) into a quantitative budget adjustment parameter (budget decay factor). Optionally, the device internally pre-configures and stores a static "overlap-decay factor" mapping table. The table divides the range of data record overlap (0 to 1) into several discrete intervals, and hardcodes a fixed budget decay factor value for each interval. For example, the table can define the following rules: if the overlap is in the interval [0, 0.2), the decay factor is 1.0; if in the interval [0.2, 0.4), the decay factor is 0.8; if in the interval [0.4, 0.7), the decay factor is 0.5; if in the interval [0.7, 1.0], the decay factor is 0.2. When the device calculates the specific data record overlap, it only needs to query the table, find the corresponding interval and get its preset decay factor. This method completely avoids real-time floating point operations, and the query speed is extremely fast, and allows the system administrator to very flexibly and nonlinearly define the relationship between risk and decay based on experience or strategy, which is not limited here.

[0042] In some embodiments, after generating the initial budget decay factor based on the data record overlap, the device further analyzes the specific values involved in the query condition parameters. First, the device queries the global frequency of the value in a pre-built sensitive value dictionary. Then, based on the global frequency, a value rarity decay factor is generated, which is inversely proportional to the global frequency, i.e., the more rare the value, the smaller the decay factor. Finally, the device selects the smaller one of the budget decay factor generated based on the overlap and the newly generated value rarity decay factor as the updated budget decay factor.

[0043] In some embodiments, the device first separates the non-sensitive query condition (e.g., "Beijing" in the query "patients in Beijing with 'Huntington's disease'") from the query condition parameters to form the condition context. Then, the device determines the condition frequency of the sensitive value ("Huntington's disease") only in the subset of data that satisfies the condition context. Next, the device makes a double determination: whether the condition frequency is lower than a preset absolute frequency threshold, and whether the ratio of the condition frequency to the global frequency is lower than a preset "drift" threshold (indicating that the value becomes abnormally rare in the specific context). If both determinations are yes, the device recalculates the value rarity decay factor based on the more accurate condition frequency to replace the factor calculated based on the global frequency; if either determination is no, the value rarity decay factor calculated based on the global frequency is maintained.

[0044] S104, after obtaining the sensitivity multiplier of the data field involved in the query statement and the permission-based budget value corresponding to the user identity, performing multiplication operation on the permission-based budget value, the sensitivity multiplier and the budget decay factor to obtain the final privacy budget value.

[0045] wherein the data field involved in the query statement refers to the specific data column or attribute that the user wants to obtain or analyze in the query request, such as "age", "diagnosis result" or "income", etc.; the sensitivity multiplier is a coefficient related to the sensitivity of the data field, which is usually a positive number less than or equal to 1, and the smaller the value, the more sensitive the field, which requires more stringent privacy protection; the user identity refers to an identifier that can uniquely determine the user initiating the query request, such as a user ID or account name; the permission-based budget value is the initial privacy budget quota pre-allocated by the system according to the user's permission level, and users with different permission levels may obtain different basic budget values.

[0046] The device parses the data fields involved in the query statement, such as identifying "average income" as the queried field from a query like "SELECT average income FROM population table WHERE age > 65". Then, the device queries a pre-configured data field sensitivity mapping table to obtain the sensitivity multiplier corresponding to the field. This mapping table is usually pre-defined by system administrators or data security experts according to the sensitivity and privacy risk of the data, for example, "HIV status" may be assigned a low sensitivity multiplier of 0.1 (indicating high sensitivity), while "city name" may be assigned a high sensitivity multiplier of 0.9 (indicating low sensitivity). Next, the device queries the user permission management system based on the user identity in the request to obtain the permission level and corresponding base budget value of the user. For example, a general researcher may be assigned a base budget value of 2.0, while a senior administrator may be assigned a base budget value of 5.0, reflecting the trust and data access permissions of different users in the system. Finally, the device performs a simple multiplication of the three factors - the permission base budget value, the sensitivity multiplier, and the budget decay factor calculated in the previous step, i.e. the final privacy budget value = permission base budget value x sensitivity multiplier x budget decay factor.

[0047] In some embodiments, when the estimated number of data records is below the preset individual identification threshold, the device converts the textual parameters in the query condition parameters in the current target query request and the query condition parameters in the historical query records into high-dimensional query condition semantic vectors based on natural language processing technology (such as the BERT model), thereby obtaining a current query condition semantic vector and multiple historical query condition semantic vectors. Then, by calculating the vector cosine similarity between the current query condition semantic vector and each historical query condition semantic vector, the device can identify a group of historical queries that are highly similar in semantics and continuous in time to the current query, forming a "continuous query sequence". Subsequently, the device determines a query intent convergence risk coefficient based on the length of the continuous query sequence and the average similarity of all query condition semantic vectors in the sequence, which is proportional to both the length and the average similarity, i.e. the longer the sequence and the higher the similarity, the greater the risk coefficient. Finally, in calculating the final privacy budget value, the device first multiplies the permission base budget value, the sensitivity multiplier, and the budget decay factor, and then divides the resulting product by the query intent convergence risk coefficient, thereby obtaining the final privacy budget value.

[0048] S105, based on the final privacy budget value, calling a differential privacy algorithm to add calibration noise to the query result, generating a privacy-protected query result and returning it to the user terminal.

[0049] wherein the differential privacy algorithm is a class of mathematical algorithms that can prevent individual information leakage while maintaining the effectiveness of data analysis, such as the Laplace mechanism or the exponential mechanism; and the calibrated noise refers to a random disturbance added to the real query result, which is accurately calculated according to the privacy budget value and the query sensitivity, and the size of which is inversely proportional to the privacy budget value.

[0050] When the device obtains the final privacy budget value, it first executes the original query statement of the user to obtain the real query result from the database. This result can be a statistical value (such as the average, the sum, or the count) or a set of data records. Then, the device selects a suitable differential privacy algorithm according to the query type. For example, for numerical statistical queries, the device usually selects the Laplace mechanism; and for categorical queries, the device can select the exponential mechanism. Subsequently, the device calculates the scale parameter of the noise (such as the b parameter of the Laplace distribution, b = Δf / ε) according to the final privacy budget value (ε) and the global sensitivity of the query (Δf, representing the maximum possible influence of a single record change on the query result). Then, the device randomly samples a noise value from the corresponding probability distribution and adds it to the real query result. Finally, the device packs this noise-processed result together with the necessary metadata (such as the query timestamp, the used privacy budget value, etc., but not including the original result) and returns it to the user terminal through a secure communication channel.

[0051] In the embodiments of the present application, since the technical features of fusing dynamic privacy budget analysis and data record overlap evaluation are adopted, in the process of executing the query request processing, the device can identify high-risk queries below the individual identification threshold, and quantify the query overlap degree by calculating the intersection and union ratio of the query influence domain and the historical influence domain, and then generate a budget decay factor based on this overlap degree, and finally determine the optimal privacy budget value combined with the user's authority and data sensitivity, effectively solving the technical problem of ignoring the actual data access mode in the prior art by only relying on the query time sequence or the fixed budget allocation mechanism, and thereby realizing risk identification and adaptive privacy budget adjustment for small-scale data sets and repeated query patterns, and improving the reliability of privacy protection.

[0052] In the above embodiments, the device can effectively identify and quantify the privacy risks caused by repeated queries of a single user by fusing the technical features of data record overlap evaluation and dynamic privacy budget adjustment, thereby improving the accuracy and flexibility of privacy protection.

[0053] However, in practical applications, in a data analysis scenario emphasizing team collaboration, different members in a collaboration group can query complementary data subsets respectively, and there is a risk of indirect inference of individual information through collaborative queries (i.e., collusion) between multiple users. The present application further integrates the technical features of collaboration collusion risk identification on the basis of retaining the aforementioned individual risk analysis capability, by identifying collaboration group members, aggregating shared query history and evaluating the overlap risk of joint queries, further improving the reliability of the privacy protection system in a complex collaboration environment.

[0054] Please refer to Figure 2 is another flowchart of a dynamic privacy budget analysis method in the embodiments of the present application.

[0055] S201, after receiving the target query request sent by the user terminal, the estimated number of data records matched with the query condition parameters is calculated by calling the database query optimizer, and the estimated number of data records and its corresponding data record set are determined as the query impact domain.

[0056] S202, after receiving the target query request, the user corresponding to the user identity identifier is identified, the collaboration user identity identifiers belonging to the same preset collaboration group constitute a collaboration group member set.

[0057] Among them, the user identity identifier represents a string or token, such as a username or access key, that can uniquely identify the current operating user and is contained in the target query request; the user refers to the real entity associated with the user identity identifier, such as a researcher or data analyst; the preset collaboration group refers to a user group pre-defined by the system administrator according to project needs or organizational structure, the members in this group are authorized to share query history and privacy budget for the common research goal; the collaboration user identity identifier refers to the user identity identifier of other members in the preset collaboration group except the current user; and the collaboration group member set is a data set containing the current user identity identifier and all other collaboration user identity identifiers.

[0058] Specifically, this step is usually started in parallel with S201. When the device receives a target query request from a user terminal, it immediately parses the user identity from it. Then, the device uses this user identity to query an internal or external user and permission management system. The core function of this management system is to maintain the mapping relationship between users and collaboration groups. The query operation aims to determine whether the current user belongs to any pre-set collaboration group. If the query result shows that the user does not belong to any collaboration group, the collaboration group member set will only contain its own user identity. On the contrary, if the query result confirms that the user is a member of a collaboration group (for example, "Lung Cancer Research Project Group"), the device will further extract the identity list of all members from the definition of this collaboration group. Finally, the device combines the identity of the current user with the identities of other collaboration group members obtained, forming a complete and de-duplicated collaboration group member set.

[0059] S203, aggregate collaboration history query records of the collaboration group member set within a pre-set time window, and extract the corresponding historical influence domain in the collaboration history query records to construct a collaboration group shared historical influence domain.

[0060] After determining the collaboration group member set, the device starts a data aggregation process. First, the device iterates through each user identity in the collaboration group member set. For each member, the device queries all historical query records within a pre-set time window. This query operation filters all records initiated by this user ID and with timestamps within the specified range from a centralized query log or historical record storage. Then, the device extracts the core content of each retrieved collaboration history query record, the historical influence domain. This historical influence domain represents the data range touched by this query. After extracting all historical influence domains of collaboration members within the time window, the device performs a large-scale set-union operation on these possibly very large and scattered historical influence domains, i.e., calculates their union. The purpose of this union operation is to collect all scattered data records accessed by different members at different time points and form a single, macroscopic "collaboration group shared historical influence domain".

[0061] In some embodiments, the construction of the collaboration group shared history influence domain can be implemented in multiple ways: optionally, an online aggregation scheme based on probabilistic data structures can be adopted. In this scheme, the device maintains a single, dynamically updated aggregated Bloom filter (or HyperLogLog and other Sketch data structures) for each collaboration group, which represents the collaboration group shared history influence domain. When any member of the collaboration group completes a query, instead of storing its history influence domain separately, the device directly merges the Bloom filter representation of the query influence domain into the aggregated Bloom filter of the collaboration group by performing a bitwise OR operation. Meanwhile, a decay mechanism can be introduced to periodically or probabilistically clear some bits in the aggregated filter to simulate the sliding effect of a preset time window. When the collaboration group shared history influence domain needs to be constructed, the device does not need to perform a time-consuming data aggregation query, but can directly obtain the latest aggregated Bloom filter of the collaboration group. Optionally, an offline batch processing scheme based on materialized views can also be adopted. In this scheme, the device utilizes the materialized view function of the database. The system will predefine a materialized view, and the logic of the view is to periodically (for example, every hour) scan all user query logs, merge (UNION) the data record IDs affected by the queries belonging to the same collaboration group and within a preset time window, and store the results. When the collaboration group shared history influence domain needs to be constructed, the device only needs to query this precomputed materialized view. This way shifts the computing pressure to the offline task in the background, so that the construction process during online query has almost no overhead, and is suitable for scenarios that have extremely strict requirements on online response time but can tolerate certain data delay. No limitation is made here.

[0062] In some embodiments, when aggregating the history influence domains, the device can assign a "user risk weight" to each member in the collaboration group according to its role, permission, or historical behavior analysis. Secondly, for each history influence domain, the device can record its frequency or recency of being accessed to form an "influence domain heat value". When constructing the collaboration group shared history influence domain, the device can generate a weighted probabilistic data structure (such as Counting Bloom Filter), in which the presence of each data record identifier is not only 0 or 1, but also the product of the user risk weight and the influence domain heat value of its corresponding query. The "collaboration group shared history influence domain" constructed in this way is no longer a flat set, but a "heat map" with a risk distribution map. When calculating the overlap degree later, the overlap with the high-weight and high-heat area will produce a greater risk signal than the overlap with the low-weight and low-heat area.

[0063] S204, determining the collaboration group shared history influence domain as a part of the history influence domain.

[0064] After the device has obtained the user's personal history influence domain and the collaboration group shared history influence domain, it will integrate the two parts before entering the overlap calculation. For example, the device will combine the collaboration group shared history influence domain with all the user's personal independent history influence domains to form an "extended history influence domain set". This set will be used as the "history query record" when calculating the data record overlap in the next step S205.

[0065] S205, when the estimated data record quantity is lower than the preset individual identification threshold, based on the user terminal's history query record, by calculating the intersection and union ratio of the query influence domain and the history influence domain, determine the average ratio of the query influence domain and the history influence domain as the data record overlap.

[0066] Specifically, the device will take the "collaboration group shared history influence domain" built in the previous step as the history influence domain. Then, the device will combine this special history influence domain with all the user's personal independent history influence domains to form an "extended history influence domain set" for calculating the overlap. Subsequently, the device starts a similar calculation process as step S102: it will calculate the intersection and union ratio of the current query's query influence domain and each history influence domain in this extended set (including the user's personal history influence domains and that aggregated collaboration group shared history influence domain) respectively, obtaining a series of single overlap ratios. Finally, by weighted averaging these single overlap ratios (for example, the ratio calculated with the collaboration group shared history influence domain can be given a higher weight), the final data record overlap is obtained.

[0067] In some embodiments, the incorporation of the collaboration group shared history influence domain into the overlap degree calculation can be implemented in various ways. Optionally, a hierarchical weighted average calculation scheme can be adopted. In this scheme, the device first independently calculates two overlap degrees: one is the "personal overlap degree" between the current query and the user's personal history influence domain, and the other is the "collaborative overlap degree" between the current query and the collaboration group shared history influence domain. Then, the device performs a weighted average of the two overlap degrees according to a preset weight, to obtain the final data record overlap degree, with the formula: final overlap degree = w personal × personal overlap degree + w collaborative × collaborative overlap degree, where w personal + w collaborative = 1. The administrator is allowed to flexibly control the relative importance of the personal behavior risk and the collaboration collusion risk in the final evaluation by adjusting the weight. For example, for highly sensitive projects, w collaborative can be adjusted to be higher, so as to more strictly review the queries related to team behavior. Optionally, a unified calculation scheme after logical merging can also be adopted. In this scheme, the device logically merges the collaboration group shared history influence domain with all the user's personal history influence domains before calculation. If a Bloom filter or other probabilistic data structure is used, the device can perform a bitwise OR operation on the Bloom filter representing the collaboration group shared history influence domain and the Bloom filters representing the user's personal history influence domains, to form a single, comprehensive history influence domain Bloom filter. Then, the device only needs to calculate the intersection-union ratio between the current query influence domain and this comprehensive history influence domain once, to directly obtain the final data record overlap degree. It can be understood that other ways can also be used to implement this step, for example, the collaboration group shared history influence domain can be regarded as an independent risk dimension, and the calculated overlap degree does not participate in the average, but directly acts as an independent multiplier factor in the final budget decay calculation, which is not limited here.

[0068] S206, generating a budget decay factor based on the data record overlap degree.

[0069] S207, after obtaining the sensitivity multiplier of the data field involved in the query statement and the permission basis budget value corresponding to the user identity identifier, performing a multiplication operation on the permission basis budget value, the sensitivity multiplier and the budget decay factor, to obtain a final privacy budget value.

[0070] Steps S206-S207 are similar to steps S103-S104 in the embodiment shown in Figure 1 The steps S103-S104 in the embodiment shown in

[0071] S208, based on the final privacy budget, calling a differential privacy algorithm to add calibration noise to the query result, generating a privacy-protected query result and returning it to the user terminal.

[0072] After the device computes the final privacy budget value (which can have been updated due to the penalty mechanism in step S208), it first executes the original target query request in the database to obtain an unprocessed, accurate true query result. Then, the device analyzes the type of the query (e.g., counting, summing, or averaging) and determines the global sensitivity (Af) of the query function, i.e., the maximum possible impact of a single data record on the query result. Subsequently, the device substitutes the final privacy budget value (e) and the global sensitivity (Af) into the noise generation formula of the selected differential privacy algorithm to compute the scale parameter of the noise distribution. For example, when using the Laplace mechanism, the scale parameter b = Af / e. Then, the device randomly draws a noise value from the parameterized Laplace distribution. Finally, the device adds the random noise value to the true query result to generate the final privacy-protected query result. This result retains the statistical properties of the original data while making it impossible for anyone to infer any individual information from the result due to the unpredictable random noise added. After adding the noise, the device encapsulates and securely transmits the privacy-protected query result back to the user terminal that initiated the request.

[0073] In some embodiments, after computing the scale of noise that needs to be added, the device can pre-evaluate the impact of the noise on the signal-to-noise ratio of the query result. If the device predicts that the signal-to-noise ratio will be lower than a preset availability threshold (i.e., the noise is too large), it will not directly return a useless result, but will abort the current return process. Instead, the device will return a prompt message to the user terminal, which contains two parts of content: one is to inform the user that the current query cannot be executed under the premise of ensuring the availability of the result due to the superposition of multiple privacy risks; the other is to actively provide one or more suggestions for query reconstruction to the user based on the analysis of the query intent. For example, the user is suggested to "relax the query conditions to include more data records", "change the average to the median to reduce the sensitivity", or "try to query a related but less sensitive field".

[0074] In the embodiments of the present application, due to the adoption of the technical feature of fusion cooperation combined collusion risk identification, in the process of executing the query request processing, the device can identify the cooperation group to which the user belongs, aggregate the shared history influence domain of all members in the group, and calculate the overlap degree of the current query and the overall behavior of the team based on this, effectively solving the technical problem that the prior art only focuses on the individual query history and ignores the potential collusion attack risk in team cooperation, thereby realizing the identification and suppression of multi-user collaborative privacy probing behavior and enhancing the security of the privacy protection system in the cooperation scenario.

[0075] An exemplary device 300 provided by the embodiments of the present application is described below. Figure 3is an exemplary hardware structure schematic diagram of the device 300 provided by the embodiments of the present application.

[0076] In some embodiments, the device 300 is a computer device or includes a computer device in the device 300. The computer device includes a processor, a memory and a network interface connected through a system bus. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The database of the computer device is configured to store data. The network interface of the computer device is configured to communicate with other terminals or servers outside through a network connection. In some embodiments, the network interface can be a wired network interface, and in some embodiments, the network interface can also be a wireless network interface. The computer program is executed by the processor to implement the method in the embodiments of the present application.

[0077] Those skilled in the art can understand that, Figure 3 The structure shown in the above is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components. The above-described embodiments are only used to illustrate the technical solutions of the present application, but not limit the technical solutions; although the technical solutions recorded in the above embodiments are described in detail, those skilled in the art should understand that the technical solutions recorded in the above embodiments can be modified, or some technical features can be replaced by equivalent features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

[0078] In the above embodiments, according to the context, the term "when" can be interpreted as meaning "if" or "after" or "in response to determining" or "in response to detecting". Similarly, according to the context, the phrase "upon determining" or "if detecting (the stated condition or event)" can be interpreted as meaning "if determining" or "in response to determining" or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)".

[0079] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk) and the like.

[0080] Those of ordinary skill in the art understand that all or part of the processes in the above embodiments can be implemented by a computer program to instruct the relevant hardware, which can be stored in a computer readable storage medium. The program can include the processes of the above method embodiments when executed. The aforementioned storage medium includes ROM or random access memory (RAM), magnetic disk or optical disk, and various media that can store program codes.

Claims

1. A dynamic privacy budget analysis method, characterized in that, Applied to a device, the method includes: After receiving the target query request sent by the user terminal, the database query optimizer is called to calculate the estimated number of data records that match the query condition parameters, and the estimated number of data records and the corresponding set of data records are determined as the query influence domain. The query request includes the user identity identifier, query statement and query condition parameters. When the estimated number of data records is lower than the preset individual identification threshold, based on the historical query records of the user terminal, the average ratio of the query influence domain to the historical influence domain is determined as the data record overlap by calculating the ratio of the intersection and union of the query influence domain and the historical influence domain. The historical query records include the historical influence domains corresponding to each query of the user terminal within the preset time window. A budget attenuation factor is generated based on the data record overlap. The budget attenuation factor is a positive number less than or equal to 1 and is inversely proportional to the data record overlap. After obtaining the sensitivity multiplier of the data fields involved in the query statement and the basic budget value of the permissions corresponding to the user identity identifier, the basic budget value of permissions, the sensitivity multiplier and the budget decay factor are multiplied to obtain the final privacy budget value; Based on the final privacy budget value, a differential privacy algorithm is invoked to add calibration noise to the query results, generating privacy-protected query results and returning them to the user terminal.

2. The method according to claim 1, characterized in that, The data record overlap is determined by calculating the ratio of the intersection to the union of the query influence domain and the historical influence domain based on the historical query records of the user terminal. Specifically, this includes: The historical queries are constructed into a time decay weight sequence according to the query time order, and the weight value of the historical query record that is closer to the current query time is larger in the time decay weight sequence. Traverse the set of data record identifiers in the historical influence domain, and perform set operations on the set of data record identifiers in the query influence domain and the set of data record identifiers in the historical influence domain to obtain the number of intersection records and the number of union records corresponding to the historical influence domain; The single overlap ratio is obtained by dividing the number of intersection records corresponding to the historical influence domain by the number of union records. Based on the time decay weight sequence, the single overlap ratio corresponding to the historical query is multiplied by the corresponding time decay weight to obtain a weighted overlap ratio. The time decay weight is inversely proportional to the time interval. The overlap of the data records is obtained by arithmetically averaging all the weighted overlap ratios.

3. The method according to claim 1, characterized in that, The step of multiplying the basic privacy budget value, the sensitivity multiplier, and the budget decay factor to obtain the final privacy budget value specifically includes: When the estimated number of data records is lower than the preset individual identification threshold, based on the query condition parameters in the target query request and the query condition parameters of the historical queries in the historical query records, the query condition parameters are converted into query condition semantic vectors to obtain the current query condition semantic vector of the current query and multiple historical query condition semantic vectors of the historical queries. By calculating the vector cosine similarity between the current query condition semantic vector and the multiple historical query condition semantic vectors, historical queries that form a continuous query sequence with the current query condition semantic vector are identified. The continuous query sequence refers to a set of time-series consecutive queries within the preset time window whose semantic similarity is higher than a preset similarity threshold. Based on the length of the continuous query sequence and the average similarity of the semantic vectors of all query conditions within the sequence, a query intent convergence risk coefficient is determined. The query intent convergence risk coefficient is proportional to both the length of the sequence and the average similarity. The final privacy budget value is obtained by multiplying the basic permission budget value, the sensitivity multiplier, and the budget decay factor, and then dividing the resulting product by the query intent convergence risk coefficient.

4. The method according to claim 3, characterized in that, Before the step of multiplying the permission base budget value, the sensitivity multiplier, and the budget decay factor to obtain the final privacy budget value, the method further includes: Query the global frequency of the relevant data field in the pre-built sensitive value dictionary; A numerical rarity attenuation factor that is inversely proportional to the global frequency is generated based on the global frequency. Choose the smaller value from the budget decay factor and the numerical rarity decay factor as the updated budget decay factor.

5. The method according to claim 4, characterized in that, The step of generating a numerical rarity attenuation factor that is inversely proportional to the global frequency specifically includes: Extract the non-sensitive query conditions that constitute the condition context from the query condition parameters; Based on the non-sensitive query conditions, determine the condition frequency of the sensitive values ​​in the subset of data that satisfies the context of the condition; Determine whether the conditional frequency is lower than a preset frequency threshold, and whether the ratio of the conditional frequency to the global frequency is lower than a preset drift threshold; If the judgment result is yes, then a numerical rarity attenuation factor that is inversely proportional to the conditional frequency is generated based on the conditional frequency. If the judgment result is negative, a numerical rarity attenuation factor that is inversely proportional to the global frequency is generated based on the global frequency.

6. The method according to claim 3, characterized in that, The step of converting query condition parameters into query condition semantic vectors specifically includes: The query condition parameters are decomposed into one or more independent condition clauses, each containing field names, operators, and values; Based on the field name and the operator, the corresponding encoded value is searched and mapped in the preset encoding table to obtain the field encoding value and the operator encoding value; The field encoding values ​​and operator encoding values ​​corresponding to the conditional clauses are used to construct the conditional clause vector; All the condition clause vectors are concatenated in a preset order to form the query condition semantic vector.

7. The method according to claim 1, characterized in that, After receiving the target query request sent by the user terminal, the method further includes the steps of calculating the estimated number of data records matching the query condition parameters by calling the database query optimizer, and determining the estimated number of data records and its corresponding set of data records as the query influence domain. Upon receiving the target query request, the user corresponding to the user identity identifier is identified, and the collaborative user identity identifiers belonging to the same preset collaborative group are identified to form a collaborative group member set; Aggregate the collaboration history query records of the collaboration group members within the preset time window, and extract the corresponding historical influence domain from the collaboration history query records to construct a shared historical influence domain for the collaboration group; The historical influence domain shared by the collaborative group is identified as part of the historical influence domain.

8. A device, characterized in that, The device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the device to perform the method as described in any one of claims 1-7.

9. A computer program product containing instructions, characterized in that, When the computer program product is run on the device, the device causes the device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the device, the device causes the device to perform the method as described in any one of claims 1-7.

Images