A privacy protection based query method and system

Abstract

The application relates to a privacy protection-based query method and system, wherein the privacy protection-based query method comprises the following steps: splitting an original query into a plurality of independent subtasks; extracting at least one entity contained in each of the subtasks and determining the privacy level of each of the entities; determining the security level of each of the subtasks based on the highest level of the entity privacy levels in each of the subtasks; determining query models matched with each of the subtasks from a candidate cloud model set and a candidate local model set based on the security levels of each of the subtasks; determining the calling sequence of each of the query models based on the association relationship of each of the subtasks; calling the query models matched with each of the subtasks based on the calling sequence; receiving the return results of each of the query models; and fusing the return results to obtain the answer to the original query, so as to consider the security of information and the accuracy of the query.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a privacy-preserving query method and system. Background Technology

[0002] Currently, AI tools are widely used across various fields. Users face a dilemma when using these tools: First, using powerful cloud-based models (such as GPT-4, Claude, Gemini, etc.) requires users to send complete conversations to external servers. This content may include personal ideas, business plans, private information, and identity data. While some service providers promise not to use user data for training, this protection relies on "corporate commitments" rather than technical architecture. User data still faces risks of leakage, being used for model improvement training, and unauthorized access by service provider personnel. Second, using locally deployed models (such as Llama, Qwen, Ollama, etc.), although the data remains entirely on the user's own device, local models have limited capabilities and cannot access the latest publicly available information on the internet in real time.

[0003] Therefore, the lack of a personal AI interaction system that enforces the isolation of private data at the architectural level means that users can only choose between local and cloud models, making it impossible to balance information security and query accuracy. Summary of the Invention

[0004] Therefore, it is necessary to provide a privacy-preserving query method and system to address the aforementioned technical issues.

[0005] In a first aspect, embodiments of this application provide a privacy-preserving query method applied to an isolated computing environment with exclusive user control. This isolated computing environment supports calling cloud-based models and local models. The method includes:

[0006] The original query is broken down into several independent subtasks;

[0007] Extract at least one entity contained in each of the subtasks and determine the privacy level of each entity; determine the security level of each subtask based on the highest privacy level of the entity in each subtask.

[0008] Based on the security level of each subtask, a query model matching each subtask is determined from the candidate cloud model set and the candidate local model set; and based on the association relationship of each subtask, the calling order of each query model is determined.

[0009] Based on the aforementioned invocation order, the query model matched by each of the subtasks is invoked;

[0010] The system receives the return results from each of the query models and merges them to obtain the answer to the original query.

[0011] In one embodiment, determining the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask includes:

[0012] Obtain user preference configuration information, as well as task information for each of the subtasks; the task information includes at least the task type and task complexity.

[0013] Based on the security level of each subtask, the user preference configuration information, and the task information, a query model matching each subtask is determined from the candidate cloud model set and the candidate local model set.

[0014] In one embodiment, the invocation of the query model matched by each of the subtasks includes:

[0015] Determine whether the query model matched by the subtask is a cloud model;

[0016] If so, the target constraint of the original query is obtained, and the subtask is reconstructed based on the target constraint. The reconstructed subtask is then sent to the matching cloud model.

[0017] If not, the subtask is sent directly to the matching local model.

[0018] In one embodiment, after determining whether the query model matched by the subtask is a cloud model, the method further includes:

[0019] Determine whether the subtask includes an entity with a preset privacy level; the entity with the preset privacy level is an entity with de-identified information.

[0020] If the subtask is included and the query model matched by the subtask is a cloud model, then the entity is reversibly de-identified, the subtask is reconstructed, and the de-identified and reconstructed subtask is sent to the matched cloud model.

[0021] In one embodiment, before invoking the query model matched by each of the subtasks, the method further includes:

[0022] Determine whether the query model matched by the subtask is a cloud model;

[0023] If so, a security enhancement strategy is applied to the subtask before retransmission. The security enhancement strategy includes at least one of the following: traffic padding, time and size normalization, out-of-order delayed transmission, generalized reconstruction, embedded semantic noise, or generation of pseudo-task packages.

[0024] In one embodiment, determining the privacy level of each of the entities includes:

[0025] Each entity is matched against a locally stored private entity table. If a match is found, the corresponding entity is determined to be at the third level.

[0026] Each entity is matched against the locally stored de-identification mapping table. If a match is successful, the corresponding entity is determined to be at the second level.

[0027] Otherwise, the corresponding entity is designated as Level 1; the privacy levels of Level 1, Level 2, and Level 3 increase sequentially.

[0028] In one embodiment, determining the security level of each subtask based on the highest level of entity privacy in each subtask includes:

[0029] If the highest level is the first level, then the security level of the corresponding subtask is determined to be the first level;

[0030] If the highest level is the second level, then the security level of the corresponding subtask is determined to be the second level;

[0031] If the highest level is the third level, then the security level of the corresponding subtask is determined to be the third level.

[0032] In one embodiment, determining the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask includes:

[0033] If the security level of the subtask is Level 1, then a matching query model is determined from the candidate cloud model set.

[0034] If the security level of the subtask is Level 2, then a matching query model is determined from the cloud models that support de-identification processing in the candidate cloud model set.

[0035] If the security level of the subtask is level three, then a matching query model is determined from the candidate local model set.

[0036] In one embodiment, the step of matching each entity with a locally stored private entity table, and determining the corresponding entity as a third-level entity if a match is successful, includes:

[0037] Each entity is precisely matched with a private entity table stored locally. If the entity has a canonical name or alias in the private entity table, the corresponding entity is determined to be at the third level.

[0038] If an exact match fails, the entity is converted into a vector, and the cosine similarity between the vector and all private entity canonical name vectors in the private entity table is calculated to obtain the maximum similarity.

[0039] If the maximum similarity value is greater than a preset threshold, the corresponding entity is determined to be at the third level.

[0040] In one embodiment, the isolated computing environment includes one of the following: a user's local personal computing device, a cloud-based virtual private instance over which the user has exclusive control, or a container instance within a trusted execution environment.

[0041] Secondly, embodiments of this application also provide a privacy-preserving query system applied to an isolated computing environment with exclusive user control. The isolated computing environment supports calling cloud-based models and local models. The system includes:

[0042] The query splitting module is used to split the original query into several independent subtasks;

[0043] The determination module is used to extract at least one entity contained in each of the subtasks and determine the privacy level of each entity; determine the security level of each subtask based on the highest level of the entity privacy level in each subtask; determine the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask; and determine the calling order of each query model based on the association relationship of each subtask.

[0044] The calling module is used to call the query model matched by each of the subtasks based on the calling order;

[0045] The fusion module is used to receive the return results of each of the query models, and merge the return results to obtain the answer to the original query.

[0046] In one embodiment, the system can be deployed as a local gateway, a cloud private instance, or an intelligent agent agent.

[0047] Thirdly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0048] Compared with the prior art, this application has the following beneficial effects:

[0049] By splitting the original query into several independent subtasks; extracting at least one entity contained in each subtask and determining the privacy level of each entity; determining the sensitivity level of each subtask based on the highest privacy level of the entity in each subtask; determining the query model matching each subtask from a candidate cloud model set and a candidate local model set based on the sensitivity level of each subtask; determining the calling order of each query model based on the association relationship of each subtask; calling the query model matching each subtask based on the calling order; receiving the return results of each query model; and fusing the return results to obtain the answer to the original query, information security and query accuracy are achieved.

[0050] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0051] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0052] Figure 1 This is a flowchart illustrating a privacy-preserving query method in one embodiment;

[0053] Figure 2 This is a block diagram of a privacy-preserving query system in one embodiment. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0055] This application provides a privacy-preserving query method applied to an isolated computing environment under the exclusive control of the user. This isolated computing environment includes, but is not limited to: the user's local personal computing device, a cloud-based virtual private instance under the user's exclusive control, and a container instance within a trusted execution environment. The isolated computing environment provides standardized communication interfaces with various mainstream AI models (OpenAI GPT series, Anthropic Claude series, Google Gemini series, and models supported by local Ollama such as Llama / Qwen) and intelligent agent platforms (such as AutoGPT, BabyAGI, SuperAGI, etc.), allowing the invocation of various cloud-based and local models through these standardized communication interfaces. Figure 1As shown, the method is applied to an isolated computing environment with exclusive user control and includes the following steps:

[0056] Step 201: Break down the original query into several independent subtasks.

[0057] Specifically, based on the semantic structure, the original query is broken down into several independent subtasks.

[0058] Step 202: Extract at least one entity contained in each of the subtasks and determine the privacy level of each entity; determine the security level of each subtask based on the highest privacy level of the entity in each subtask.

[0059] Specifically, the Named Entity Recognition (NER) function of the local Small Language Model (SLM) is invoked to extract all entities in each subtask. Entities include noun phrases, proper nouns, item names, etc., and the privacy level of each entity is determined. Then, based on the privacy levels of the entities in each subtask, the security level of each subtask is determined. The privacy level of an entity is positively correlated with the security level of the subtask; the higher the privacy level, the higher the security level. Furthermore, the security level of a subtask is determined according to the principle of the highest privacy level among all entity privacy levels in that subtask.

[0060] In some embodiments, the Named Entity Recognition (NER) function of the local small language model (SLM) can be invoked first to extract all possible entities from the user's original query and determine the privacy level of each entity. Then, based on the privacy level and semantic structure of the entities, the original query is split into several independent subtasks.

[0061] Step 203: Based on the security level of each subtask, determine the query model that matches each subtask from the candidate cloud model set and the candidate local model set; and based on the association relationship of each subtask, determine the calling order of each query model.

[0062] The security level of a subtask determines whether it is suitable for outsourcing. For subtasks with extremely high security levels, they should be handled entirely by the local model, and these subtasks should be forcibly routed to the local model for processing, generating no external network requests. They cannot be processed by the cloud model to ensure the security of the subquery task. For subtasks with extremely low security levels, they can be processed by either the local model or the cloud model. Based on the above security level constraints, each subtask is constrained to be processed by either the local model or the cloud model. Furthermore, the most suitable query model for each subtask can be determined from the candidate cloud model set or the candidate local model set by combining constraints such as subtask attributes and model attributes.

[0063] Then, based on the relationships between the subtasks (e.g., subtask B references the result of subtask A), a subtask dependency graph is constructed. Based on the subtask dependency graph, a topological sort is performed to obtain the serial / parallel calling order. Subtasks without dependencies can be called in parallel.

[0064] Step 204: Based on the calling order, call the query model matched by each of the subtasks.

[0065] Based on the aforementioned invocation order, the query models matched by each subtask are invoked in parallel or sequentially. For example, subtask A matches a cloud-based model a, and subtask B matches a local model b. If subtask A and subtask B are not related, cloud-based model a and local model b can be invoked in parallel. If subtask A and subtask B are related, and subtask B references the result of subtask A, then cloud-based model a must be invoked first. After cloud-based model a returns its result, the result returned by cloud-based model a, along with the result from subtask B, is then sent to local model b for querying.

[0066] Step 205: Receive the return results of each of the query models, and merge the return results to obtain the answer to the original query.

[0067] In this embodiment, the original query is split into several independent subtasks; at least one entity contained in each subtask is extracted, and the privacy level of each entity is determined; based on the highest privacy level of the entity in each subtask, the sensitivity level of each subtask is determined; based on the sensitivity level of each subtask, a query model matching each subtask is determined from a candidate cloud model set and a candidate local model set; and based on the association relationship of each subtask, the calling order of each query model is determined; based on the calling order, the query model matching each subtask is called; the return results of each query model are received, and the return results are merged to obtain the answer to the original query, thus achieving information security and query accuracy.

[0068] In one embodiment, determining the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask includes the following steps:

[0069] Step 301: Obtain user preference configuration information and task information for each of the subtasks; the task information includes at least the task type and task complexity.

[0070] User preference configuration information is stored locally, and different users have corresponding preference configuration information.

[0071] User preference configuration information includes: role tags (such as "product manager" or "researcher"), cost sensitivity of the model (value between 0 and 1), latency sensitivity of the model (value between 0 and 1), accuracy sensitivity of the model (value between 0 and 1), and a list of preferred models.

[0072] The task information for subtasks includes: task type and task complexity. Task types are categorized by SLM and include: data retrieval, logical reasoning, creative writing, code generation, numerical computation, translation, etc.; complexity is evaluated by SLM and includes low, medium, and high complexity levels.

[0073] Step 302: Based on the security level of each subtask, the user preference configuration information, and the task information, determine the query model that matches each subtask from the candidate cloud model set and the candidate local model set.

[0074] First, based on the security level of each subtask, determine whether each subtask is routed to a cloud model or a local model for querying; then, based on the user preference configuration information and the task information, determine the query model that best matches each subtask from the candidate cloud model set or the candidate local model set.

[0075] In some embodiments, after determining whether each subtask is routed to a cloud model or a local model for querying based on the security level of each subtask, the most matching query model can be directly specified for each subtask.

[0076] In one embodiment, invoking the query model matched by each of the subtasks includes the following steps:

[0077] Step 401: Determine whether the query model matched by the subtask is a cloud model.

[0078] Specifically, based on the security level of each subtask, it is determined whether each subtask is routed to the cloud model or queried in the local model.

[0079] Step 402: If yes, then obtain the target constraint of the original query, reconstruct the subtask based on the target constraint, and send the reconstructed subtask to the matching cloud model.

[0080] In practice, the reconstruction is implemented using intent rewriting. First, the local SLM is used to extract target constraint keywords from the original query, such as "weight reduction," "optimization," "strength improvement," "cost reduction," and "trend analysis." These constraints will be used for subsequent query reconstruction. Then, using a prompt word template, the following query is rewritten to retain the target constraints ({intent constraint list}). The SLM generates the rewritten query text for the subtasks, for example, rewriting "the latest progress in lightweight alloy materials in 2026" to "retrievable lightweight alloy materials for structural weight reduction in 2026" and sending it to the matching cloud model.

[0081] In this step, for subtasks that need to be sent to an external cloud model, the query is first reconstructed to preserve the target constraints of the original query and ensure the relevance and accuracy of the results returned by the cloud.

[0082] Step 403: If not, the subtask is sent directly to the matching local model.

[0083] For subtasks that need to be sent to the local model, atomic task queries can be sent directly. However, in practice, refactoring can still be performed to improve targeting.

[0084] In one embodiment, after determining whether the query model matched by the subtask is a cloud model, the method further includes the following steps:

[0085] Step 501: Determine whether the subtask includes an entity with a preset privacy level; the entity with the preset privacy level is an entity with de-identified information.

[0086] Step 502: If the subtask is included and the query model matched by the subtask is a cloud model, then the entity is reversibly de-identified and the subtask is reconstructed, and the de-identified and reconstructed subtask is sent to the matched cloud model.

[0087] In this embodiment, if the query model matched by the subtask is a cloud model and includes entities with a preset privacy level, i.e. entities with desensitized information, then the entity needs to be reversibly desensitized before the subtask is reconstructed to ensure the security of the subtask sent to the external cloud model.

[0088] In one embodiment, before invoking the query model matched by each of the subtasks, the method further includes the following steps:

[0089] Step 601: Determine whether the query model matched by the subtask is a cloud model.

[0090] Specifically, based on the security level of each subtask, it is determined whether each subtask is routed to the cloud model or queried in the local model.

[0091] Step 602: If yes, then perform a security enhancement strategy on the subtask before sending it. The security enhancement strategy includes at least one of the following: traffic padding, time and size normalization, out-of-order delayed sending, generalized reconstruction, embedded semantic noise, or generating pseudo-task packages.

[0092] In practice, whether to implement security enhancement strategies is configurable. If the user enables "Enhanced Security Mode" in the settings, one or more of the following strategies will be enabled to obfuscate traffic characteristics and prevent attackers from indirectly inferring user privacy by analyzing communication patterns (time, frequency, packet size, frequency of placeholder appearance). The user can select which strategy to use in the configuration options.

[0093] In one embodiment, determining the privacy level of each entity includes the following: matching each entity with a locally stored private entity table; if a match is successful, the corresponding entity is determined to be at the third level; matching each entity with a locally stored de-identified mapping table; if a match is successful, the corresponding entity is determined to be at the second level; otherwise, the corresponding entity is determined to be at the first level; wherein the privacy levels of the first, second, and third levels increase sequentially.

[0094] In this embodiment, each entity is assigned a privacy level, and a three-level classification system is adopted:

[0095] The third level, L3 (extremely high privacy), encompasses entities such as users' private ideas, business plans, unpublished designs, and personally identifiable information (e.g., ID card number, mobile phone number, email address). These entities are stored in a private entity table within a local private knowledge base. Such entities cannot leave the user-controlled, isolated computing environment in any way.

[0096] The second level, L2 (Sensitive Information): This covers information that is sensitive but can be sent externally after being anonymized. These entities cannot be sent in plaintext, but can be sent to external cloud services after reversible anonymization (replacing them with placeholders). These entities are pre-stored in an anonymization mapping table in a local private knowledge base. If the anonymization mapping table fails to match, regular expression matching is performed, specifically for identifying personally identifiable information with a fixed format, including but not limited to: ID card numbers, mobile phone numbers, email addresses, bank card numbers, etc. A successful match assigns the entity a privacy level of L2.

[0097] Level 1, L1 (Public Information): This refers to ordinary nouns or factual descriptions that do not possess privacy attributes and can be directly sent to external cloud services.

[0098] For each entity extracted from the original query, it is first matched in the private entity table. If the entity matches the private entity table stored locally, the entity is directly assigned a privacy level of Level 3 (L3). If it does not match, it is matched in the de-identified mapping table. If the entity matches the de-identified mapping table stored locally, the entity is directly assigned a privacy level of Level 2 (L2). If neither the private entity table nor the de-identified mapping table matches, the entity is assigned a privacy level of Level 1 (L1).

[0099] In one embodiment, determining the security level of each subtask based on the privacy level of each entity in each subtask includes: determining the security level of each subtask based on the highest level of the privacy levels of all entities in each subtask; specifically, if the highest level is a first level, then the security level of the corresponding subtask is determined to be a first level; if the highest level is a second level, then the security level of the corresponding subtask is determined to be a second level; if the highest level is a third level, then the security level of the corresponding subtask is determined to be a third level.

[0100] Specifically, the security level of subtasks is determined according to the "highest level principle," and the specific mapping rules are as follows:

[0101] Level 1 (S3): If a subtask contains at least one entity with an entity privacy level of L3, the security level of the subtask is directly determined to be S3 (fully local processing). The subtask will be forced to be processed in the local model and will not generate any external network requests, regardless of whether it contains entities at the L2 or L1 level.

[0102] Level 2 (S2): If a subtask does not contain any L3-level entities but contains at least one L2-level entity, then the security level of the subtask is determined to be S2 (external release after de-identification). When processing this subtask, all L2 entities must first undergo reversible de-identification (replacing them with placeholders) before it can be sent to external services.

[0103] Level 3 (S1): If a subtask contains neither L3 nor L2 level entities (i.e., all entities are L1 level), then the security level of the subtask is determined to be S1, and it can be sent directly to external services in plaintext.

[0104] In one embodiment, if the security level of the subtask is level 1, a matching query model is determined from the candidate cloud model set; if the security level of the subtask is level 2, a matching query model is determined from the cloud models that support de-identification processing in the candidate cloud model set; if the security level of the subtask is level 3, a matching query model is determined from the candidate local model set.

[0105] In one embodiment, the step of matching each entity with a locally stored private entity table, and determining the corresponding entity as a third-level entity if a match is successful, includes the following steps:

[0106] Step 701: Each entity is precisely matched with the private entity table stored locally. If the canonical name or alias of the entity exists in the private entity table, the corresponding entity is determined to be at the third level.

[0107] For each entity extracted from the original query, an exact match is first performed on the private entity table stored locally in the local private knowledge base. If the entity is exactly equal to a stored canonical name or exists in its alias list, the entity is directly assigned the privacy level L3, and the associated canonical name is recorded.

[0108] Step 702: If exact matching fails, the entity is converted into a vector, and the cosine similarity between the vector and all private entity canonical name vectors in the private entity table is calculated to obtain the maximum similarity value.

[0109] Step 703: If the maximum similarity value is greater than a preset threshold, then the corresponding entity is determined to be at the third level.

[0110] If an exact match fails, a fuzzy vector similarity match is performed: the entity text is converted into a vector using a local embedding model (such as a quantized version of all-MiniLM-L6-v2), the cosine similarity between this vector and all private entity canonical name vectors in the local private knowledge structure is calculated, the highest similarity value and its corresponding canonical name are obtained, and this similarity is compared with a dynamic threshold. If the similarity exceeds the dynamic threshold, the entity is automatically assigned an entity privacy level of L3 and associated with the matched canonical name, and the entity is automatically added as an alias to the alias list of that canonical name.

[0111] The dynamic threshold is not a fixed value, but is dynamically calculated based on the number of entities in the current private knowledge base, the dimensional distribution of the embedded model, and the user's historical feedback (false positive rate, false negative rate).

[0112] The following is a specific embodiment illustrating a privacy-preserving query method that operates in an isolated computing environment bound to the user's identity and exclusively controlled by the user. The method includes the following steps:

[0113] Step 1: Construct the candidate model capability matrix.

[0114] The candidate model capabilities matrix includes information on each cloud model and each local model that can be called, specifically including: model ID and name, supported task types and applicability scores (such as inference, writing, code generation, search, analysis, etc., scored from 0 to 100), call cost, average response latency (in milliseconds), benchmark test accuracy score (0 to 100), whether it supports desensitized placeholder formats (such as <ENT_number>), and whether it supports real-time online search. The candidate model capabilities matrix can be cached locally and updated regularly, or pulled from the cloud in real-time with user authorization.

[0115] Step 2: Split the original query into several independent subtasks and security level mappings, specifically including the following subtasks.

[0116] Step 2.1: Entity extraction.

[0117] Invoke the named entity recognition (NER) function of the local SLM to extract all possible entities (noun phrases, proper nouns, project names, etc.) from the user's original query.

[0118] Step 2.2: Intent constraint extraction.

[0119] Invoke the local SLM to extract the target constraint keywords in the query, such as "weight loss", "optimization", "strength improvement", "cost reduction", "trend analysis", etc. These constraints will be used for subsequent query reconstruction.

[0120] Step 2.3: Entity privacy level determination.

[0121] Assign an entity privacy level to each entity, using a three-level classification system: First Level, Second Level, Third Level.

[0122] Step 2.4: Subtask splitting and security level mapping.

[0123] According to the entity level and semantic structure, split the original query into several independent subtasks. Each subtask includes: task text (the original text segment or the text after preliminary cleaning), subtask security level (S3 / S2 / S1), task type (classified by the SLM, such as: data retrieval, logical reasoning, creative writing, code generation, numerical calculation, translation, etc.), complexity (low / medium / high, evaluated by the SLM), whether real-time online connection is required (boolean value), and intent constraint list (inherited from Step 2.2). Among them, the subtask security level follows the "highest level principle" for mapping.

[0124] In an exemplary embodiment: The user inputs the original query: Combine the latest progress of lightweight alloy materials in 2026 and give weight loss optimization suggestions for the 'Flying Wheel' sketch plan I drew yesterday.

[0125] After the above steps, two subtasks are output:

[0126] Subtask A: Text: Latest progress in lightweight alloy materials in 2026; Contains entity: Latest progress in lightweight alloy materials in 2026 (L1); Does not contain L3 or L2 entities, determine its safety level = S1; Task type: Data retrieval, Network required: Yes, Intent constraints: ["weight reduction", "optimization"];

[0127] Subtask B: Text: Flying Wheel sketch scheme; Contains entity: "Flying Wheel" (L3); Contains at least one L3 entity to determine its security level = S3; Task type: Private knowledge retrieval, Internet connection required: No, Intent constraint: [];

[0128] Step 3: Perform reversible desensitization.

[0129] Reversible data masking is performed on subtasks with a security level of S2 (i.e., those subtasks that do not contain L3 entities but contain L2 entities). S3-level subtasks are not masked and distributed externally; instead, they are processed entirely locally. The core data structure is a data masking mapping table (locally encrypted and stored, such as in an SQLCipher database), as shown in Table 1, containing the following fields:

[0130] Table 1

[0131]

[0132] The specific workflow is as follows: For each entity with a privacy level of L2 in the subtask with a security level of S2, the `get_or_create_placeholder` function is called. Input: The original entity string, and optionally an associated canonical name (from the fuzzy matching result); if an associated canonical name exists, the mapping table is queried using the canonical name as the key. If it exists, `last_access` and `access_count` are updated, the original entity is added to aliases (if it does not already exist), and the existing placeholder is returned. If no associated canonical name exists, an exact match is performed: if the original entity itself already exists as a canonical name, its placeholder is returned directly. Otherwise, a new entry is created: a new placeholder (auto-incrementing number) is generated, the original entity is encrypted and stored as a canonical_name, aliases are initialized to an empty array, the current time is recorded, and the new placeholder is returned.

[0133] In this embodiment, for the text of subtask S2, all L2 entities (including aliases) are replaced with the corresponding placeholders to obtain the anonymized query text. For subtask S3, no anonymization or external transmission is performed; it is processed directly by the local model. For subtask S1, it is sent directly to an external service without anonymization.

[0134] Because the mapping table is persistently stored locally and supports alias normalization, the same L2 entity will be mapped to the same placeholder when it appears at different times and in different sessions (e.g.,<ENT_001> External models seeing the same placeholder in different dialogues can maintain contextual coherence (e.g., understanding).<ENT_001> (Referring to the same thing in two consecutive conversations). Users can actively "reset" the mapping of an entity (delete the mapping record and generate a new placeholder the next time it appears), or "completely delete" the entity and all its associated data.

[0135] Step 4: Intelligent routing and orchestration, which includes the following sub-steps.

[0136] Step 4.1: Receive the subtask list from Step 3, select the optimal execution model for each subtask, and arrange the calling order. Input: Subtask list (each subtask includes: security level, task type, complexity, network connection required, intent constraints), read user preferences (role, cost / latency / accuracy sensitivity), and candidate model capability matrix.

[0137] Step 4.2: Enforce privacy constraint rules: If the subtask security level is S3, then force routing to the local model (without generating any external network requests). The local model can be a lightweight SLM built into the system, or a user-deployed local model (such as Llama 13B). If the subtask security level is S2, then only models that "support de-identification placeholders" are selected from the candidate models. If no candidate model supports de-identification placeholders, then fall back to the local model and prompt the user. If the subtask security level is S1, there are no additional constraints, and all cloud models can be selected.

[0138] Step 4.3: Execute functional constraint rules: If the subtask requires internet access, only select models that support real-time online search. If the subtask type is "numerical calculation" or "simple formula" and the security level is S1, then local models are preferred.

[0139] Step 4.4: Implement the comprehensive scoring rules:

[0140] Calculate the overall score for each candidate model:

[0141] score = w1×(acc / 100) + w2×(1 - cost / max_cost) + w3×(1 - latency / max_latency) + w4×(task_score / 100);

[0142] In this matrix, w1, w2, and w3 are weights derived from user preference configuration information (summing to 1 after normalization). The weight w4 is fixed at 0.2. acc is the model's accuracy score, cost is the model's invocation cost, latency is the model's average response latency, and task_score is the model's suitability score for the task type, all obtained from the candidate model matrix. max_cost is the maximum invocation cost, and max_latency is the maximum response latency.

[0143] The model with the highest score is selected as the optimal model to use. If multiple models have similar scores (difference < 0.05), the one with the lowest cost can be selected.

[0144] Users can choose from three modes to determine the optimal model. Mode 1: Fully Automatic Mode (default), which automatically makes decisions according to the rules described above. Mode 2: Preference-Guided Mode, where users can manually adjust the weight sliders for cost, latency, and accuracy, and the system calculates a score accordingly. Mode 3: Manual Mode, where users directly specify the optimal model for each subtask.

[0145] Step 4.5: Orchestration and Execution. Construct a subtask dependency graph: based on the referential relationships in the subtask text (e.g., subtask B references the result of subtask A) or the order explicitly specified by the user. Perform topological sorting to obtain a serial / parallel execution plan. Subtasks without dependencies can be invoked in parallel. De-identify subtask S2; subtask S1 can be directly sent to the external cloud model; subtask S3 is sent to the local model.

[0146] Step 5: Perform query restructuring and de-identification, sending subtasks with security levels S1 or S2 to the external model selected by the route, and integrating the returned results with local private knowledge. This includes the following sub-steps.

[0147] Step 5.1: Query Refactoring. For subtasks that need to be sent to an external model, query refactoring is performed first to preserve the target constraints of the original query while hiding private entities. The refactoring is implemented using intent rewriting: the local SLM is invoked, using the prompt template: "Rewrite the following query to preserve the target constraints ({intent constraint list}) and do not mention any private entity names: {subtask text}". The SLM generates the rewritten query text, for example, rewriting "Latest progress in lightweight alloy materials in 2026" to "Retrieve the latest lightweight alloy materials that can be used for structural weight reduction in 2026".

[0148] Before sending, a lightweight rule-and-model hybrid refactoring validator is used to check whether the rewritten text still contains any L2-level private entity keywords or patterns (e.g., matching canonical names or aliases in a desensitized mapping table). If a leak is detected, a more conservative "generalized refactoring" strategy is used, such as generalizing the query to "latest advances in materials science in 2026".

[0149] Step 5.2: De-identify and send out the de-identified subquery task (for S2 subqueries, the de-identified replacement has been performed) to the external cloud model selected by the route. The request does not contain any original private entities.

[0150] Step 5.3: Receive external results. Receive the response text returned by the external cloud model. This response may contain placeholders (e.g., ...).<ENT_001> ).

[0151] Step 5.4: De-identification. Using the locally stored de-identification mapping table, all placeholders in the response text are restored to their original private entities (canonical names). Specifically, the mapping table is traversed, and each placeholder is replaced with its corresponding canonical_name.

[0152] Step 5.5: Local Fusion. This step involves structurally fusing the de-anonymized external results with the retrieved local private knowledge (e.g., the sketch parameters of the "flying wheel"). The fusion method varies depending on the task type.

[0153] For "report generation" tasks, the content of each part is filled in according to the preset template (title, introduction, body, conclusion). For "question and answer" tasks, private knowledge and external information are combined into a complete prompt, and then the local SLM is called to generate the final answer. During the fusion process, L3-level private entities are presented in the original text form, and the final output is the answer visible to the user.

[0154] Compared with the prior art, the embodiments of this application have the following beneficial effects:

[0155] By forcing the data processing logic to run in an isolated computing environment under the exclusive control of the user, and executing the rule that "L3 entities must not leave the local machine and S2 subtasks containing L2 entities must be anonymized before being sent out", the unroutable nature of all original private data without anonymization protection is achieved.

[0156] "Reversible anonymization" and "query reconstruction" are bound together as an inseparable technical loop. Reversible anonymization protects L2-level entities from disclosure; query reconstruction preserves the target constraints of the original query, making the results returned in the cloud more targeted; and the reversible principle enables the precise integration of public information and private knowledge, achieving a "safe and intelligent" effect.

[0157] Through a persistent desensitization mapping table and alias normalization mechanism, entities at the same L2 level and their aliases are mapped to the same placeholders across different sessions. This enables external models to maintain contextual consistency across sessions (e.g., understanding...).<ENT_001> (Referring to the same thing in both dialogues), while the cloud still doesn't know.<ENT_001> The true meaning of .

[0158] In some embodiments, if the enhanced security mode is enabled, the outgoing subtasks are sent after a security enhancement strategy is executed. The security enhancement strategy includes at least one of the following: traffic padding, time and size normalization, out-of-order delayed sending, generalized reconstruction, embedded semantic noise, or generation of pseudo-task packages.

[0159] Strategy 1: Traffic Filling. Each time a real de-identified query is sent, the system automatically generates several (3 by default) pseudo-queries. The pseudo-queries are constructed by randomly selecting 1-2 entity placeholders from the local private knowledge base (but these do not correspond to any real L2 private entities; they are merely random strings, such as...).<ENT_FAKE_001> A topic template (e.g., aerospace interior materials, beverage can aluminum alloy market, children's toy safety standards) is randomly selected from a general knowledge graph template library. Placeholders are combined with the template to form a complete pseudo-query sentence. The packet size (number of bytes) of the pseudo-query is adjusted to match the real query by padding with meaningless characters. The real query and the pseudo query are sent in a random order, with the sending interval following a Poisson distribution (average interval of 30 seconds) to mimic the behavior patterns of real users.

[0160] Strategy 2: Time and Size Normalization. Force all outbound requests to adhere to a uniform time interval (e.g., 30 seconds) and a fixed message length (e.g., 1024 bytes). Short queries are automatically padded with meaningless characters (such as spaces or random letters) to the fixed length; long queries are split into multiple fixed-length packets and sent sequentially.

[0161] Strategy 3: Out-of-order delayed sending. All user requests (including real and fake queries) within a certain time period (e.g., 5 minutes) are temporarily stored, then sent out in random order with a random delay (0.5–2 seconds). This prevents attackers from correlating the timeline of requests with the user's real-time actions.

[0162] Strategy 4: Generalized Restructuring. For queries that have already been intended for rewriting, further blur them into broader expressions. For example, rewrite "search for light alloys that can be used for structural weight reduction in 2026" as "advances in new materials science in 2026". This strategy sacrifices some specificity but greatly reduces the risk of being inferred from a specific research field.

[0163] Strategy 5: Embedded semantic noise. During the desensitization mapping, in addition to the real L2 private entity placeholders, several random placeholders are generated and inserted (e.g.,<ENT_NOISE_001> These fake placeholders are discarded directly in the external returned results. Attackers see multiple placeholders and cannot determine which are real.

[0164] Strategy 6: Pseudo-task wrapping. The real query is wrapped in a larger, seemingly reasonable pseudo-task and sent to the external model. For example, if the real intent is to optimize wheels, the system might construct a request like: "Please write an assignment for a materials science student on 'Exploring different applications of lightweight alloys in automobiles, bicycles, and construction.'" If the assignment text returned by the external model contains useful alloy information, the system will extract the useful parts for integration using keyword extraction and other methods; irrelevant content such as "bicycle" will be discarded.

[0165] The enhanced security mode mentioned above is disabled by default to maintain low latency. Users can flexibly enable it according to their own privacy needs and choose which sub-policies to enable.

[0166] In this embodiment, by employing strategies such as traffic padding, time normalization, and generalized reconstruction provided by the enhanced security mode, attackers can effectively prevent inferences about user privacy from being made indirectly by analyzing communication patterns (time, frequency, packet size, placeholder distribution). These strategies can be flexibly enabled according to user needs, providing defense in depth.

[0167] The privacy-preserving query method of this application is illustrated below through several specific embodiments:

[0168] Example 1: Local Deployment Model (Optimized by Designer "Flying Wheel")

[0169] Hardware environment: The user uses a regular laptop (Windows 11, 8GB RAM, Intel i5-1235U) with the desktop application "Privacy AI Gateway" of this application installed.

[0170] Prerequisites: Upon first launch of the application, the system automatically starts the local SLM (quantized Phi-3mini, approximately 3.8 billion parameters) and the local embedded model (all-MiniLM-L6-v2 quantized version) in the background. The system creates an encrypted database knowledge.db in the user's document folder.

[0171] User actions: Enable the "Privacy Protection Mode" switch in the system tray (enabled by default). Open the gateway chat interface and select the backend model as "GPT-4" (the user has pre-filled their API key, which is stored in a local encrypted vault).

[0172] User input: Based on the latest advancements in lightweight alloy materials in 2026, please provide weight reduction optimization suggestions for the 'flying wheel' sketch I drew yesterday.

[0173] Internal system processing flow:

[0174] 1. Semantic parsing and entity extraction: Local SLM extracts entities: ["Latest progress in lightweight alloy materials in 2026", "Flying wheel", "Sketch scheme"]. Extracts intent constraints: ["Weight reduction", "Optimization"].

[0175] 2. Entity privacy level determination:

[0176] For "Flying Wheel": The system queries the local private knowledge base. On the first run, the base is empty, and exact matching fails. Vector similarity matching also yields no match. The system prompts the user: A new entity 'Flying Wheel' has been detected. Do you want to mark it as private? The user clicks "Yes," and the system sets its entity privacy level to L3 and stores it in the knowledge base. Placeholders are allocated as follows.<ENT_001> .

[0177] For "Latest progress in lightweight alloy materials in 2026": No match found, classified as L1.

[0178] The "sketch plan" is processed along with the "flying wheel" as supplementary information.

[0179] 3. Subtask decomposition and security level mapping (highest level principle):

[0180] Subtask 1: Text="Flying Wheel Sketch Scheme", contains L3 entities, security level = S3.

[0181] Subtask 2: Text="Latest progress in lightweight alloy materials in 2026", contains L1 entity, security level=S1.

[0182] 4. Intelligent routing decision:

[0183] Subtask 1 (S3) forces routing to the local model.

[0184] Subtask 2 (S1) is assigned to GPT-4 because the user preference is "accuracy priority" and GPT-4 has the highest accuracy score (92) in the candidate model matrix. The cost is slightly higher but acceptable.

[0185] 5. De-identification and Query Restructuring:

[0186] Subtask 1: Execute directly locally, call the local memory retrieval function, and return the parameters of the "flying wheel" sketch (hub diameter 30cm, spoke structure, current weight 2.5kg).

[0187] Subtask 2: Intent Rewrite. Call the local SLM to rewrite "Latest Advances in Lightweight Alloy Materials in 2026" to "Retrieve the latest lightweight alloy materials available for structural weight reduction in 2026". Validator check passed (no L3 or L2 entities). This subtask does not contain L2 entities, so no desensitization is required; it is sent directly to the GPT-4 API.

[0188] 6. External Returns and Fusion:

[0189] GPT-4 reports: Lightweight alloys emerging in 2026 include silicon carbide reinforced aluminum alloys (density 2.7, specific strength 280) and nanocrystalline magnesium alloys (density 1.8, specific strength 320), etc.

[0190] Anti-sensitization: No placeholder, use directly.

[0191] Local fusion: Combine private sketch parameters with publicly available material information to form prompts, and call the local SLM to generate the final answer.

[0192] 7. Output: Users see the complete optimization suggestions, with "Flying Wheel" presented in its original form. The term "Flying Wheel" has never been seen in the cloud-based GPT-4.

[0193] Cross-session verification: The next day, the user asked again, "If my flying wheel design uses magnesium-lithium alloy, will the strength be sufficient?" The system used fuzzy matching to associate "flying wheel" with the existing specification name "flying wheel," using the same placeholder.<ENT_001> If the user chooses to send the query to the cloud, the cloud will see it.<ENT_001> Because the placeholders are consistent, the context can be understood.

[0194] Example 2: Cloud Private Instance Model

[0195] Scenario: The user is the CTO of a small startup who wants to use the stronger computing power of the cloud to run a local SLM, but still requires data sovereignty.

[0196] Deployment method: The user purchases a pay-as-you-go ECS instance (g7.xlarge, 4 cores, 16GB) on Alibaba Cloud, selecting a specification that supports Trusted Execution Environment (TEE). The user logs into the instance and installs the gateway software (Docker image) provided in this application. The user generates an RSA key pair, saves the private key on their local computer, and uploads the public key to the instance for encryption and decryption.

[0197] After the instance starts, all data processing (semantic parsing, de-identification mapping table, private knowledge base) is performed in the encrypted memory of the TEE, which cannot be read by the cloud platform administrator.

[0198] Users connect to the instance's API endpoint via a client on their local computer.

[0199] Processing flow: Exactly the same as in Example 1, but the computation occurs in a cloud instance. Users can destroy the instance at any time, and all data is destroyed along with the instance or exported and backed up by the user.

[0200] Beneficial effects: Users gain access to cloud computing power while retaining data sovereignty. Even if the cloud platform is attacked, attackers will not obtain the decryption key and will be unable to read L3-level private entity data.

[0201] Example 3: Agent Auditing Pattern

[0202] Scenario: The user uses the AutoGPT agent to automatically perform the task: "Organize the 'Flying Wheel' project materials and send a weekly report email to the team".

[0203] Deployment method: Users run the application gateway locally and configure it to "intelligent agent agent mode". AutoGPT network requests are set to go through the proxy port of this gateway (e.g., 127.0.0.1:8080).

[0204] Processing flow:

[0205] 1. AutoGPT generates the first request: calls the tool read_file with the parameter path=" / docs / flywheel_design.pdf".

[0206] 2. The gateway detects that the User-Agent contains "AutoGPT" and enters audit mode.

[0207] 3. The gateway parses the request content and identifies the file path as containing the potentially sensitive keyword "flywheel" (the user had previously marked "flywheel" as an entity with an L3 privacy level, aliased as "flywheel"). Therefore, the request is determined to contain an L3-level private entity.

[0208] 4. The gateway intercepts the request and displays a confirmation dialog box for the user:

[0209] AutoGPT attempted to read the file ' / docs / flywheel_design.pdf', which contains the private entity 'Flywheel' (entity privacy level L3). Allow? The user clicked "No".

[0210] 5. The gateway returns an error response to AutoGPT: "Request rejected by user".

[0211] 6. AutoGPT received an error and adjusted its plan: skipped the file reading step and generated the weekly report based solely on existing publicly available information.

[0212] 7. In subsequent requests, AutoGPT calls the send_email tool, and the recipient list includes team@company.com (regular expression matching is L2 level). The gateway determines the security level of this request's subtask to S2 and anonymizes the recipient email address.<EMAIL_TEAM> The email was then sent to the email API, and although the email was actually sent successfully, the external API did not know the real email address.

[0213] Beneficial effects: Prevents agents from reading private files or sending sensitive information without the user's knowledge. Unlike static access control (such as operating system file permissions), this solution, based on semantic analysis of request content, can intercept agents attempting to send private data via API.

[0214] Example 4: Memory Portability (Switching from GPT-4 to Native Llama)

[0215] Scenario: A user has been using GPT-4 for a long time and has accumulated a large amount of dialogue history and L3-level private entities (such as Flying Wheel and Project X). Now they want to switch to a local open-source Llama 3 model to reduce costs while retaining all historical knowledge.

[0216] Operating steps:

[0217] 1. Click the "Export Memory" button on the gateway interface. The system will pop up export settings: select the content to export (L3 private entities, dialogue history, vector index), and select encrypted export (use user password protection).

[0218] 2. The system generates a JSON file memory_export_20260604.json.

[0219] 3. The user installs Llama 3 locally (via Ollama) and selects "Local Llama 3" as the backend model in the gateway.

[0220] 4. Click "Import Memory" and select the JSON file mentioned above. After system decryption, the L3 private entity will be injected into the Llama 3 context window (mounted via system prompts or a vector database), and the dialogue history will be loaded as seed data.

[0221] 5. The user continues to ask: "Do you remember the Flying Wheel I asked about before? Can you change some parameters for me now?" The gateway automatically searches its memory and identifies "Flying Wheel" (entity privacy level L3), and can reference historical conversation content in its answer.

[0222] Beneficial effects: Users are not locked into any single AI model and can freely switch models without losing knowledge. This is something that federated learning fine-tuning schemes cannot achieve (the weights of a fine-tuned model cannot be directly transferred to another model with a different architecture).

[0223] Example 5: Enhanced Security Mode (Countering Side-Channel Attacks)

[0224] Scenario: A user is conducting preliminary patent research and is concerned that even anonymized search patterns may reveal their research area (e.g., frequent searches for lightweight alloys might suggest the development of transportation vehicles). Therefore, they activate enhanced security mode and enable "traffic filling" and "time normalization".

[0225] User settings: Traffic filling quantity = 3, time interval = 30 seconds, fixed packet length = 1024 bytes.

[0226] Real search result: "Lightweight alloys that can be used for structural weight reduction in 2026" (approximately 30 characters long).

[0227] Processing flow:

[0228] 1. The system generates 3 pseudo queries, for example:

[0229] False query 1: "Thermal stability of composite materials for aerospace interiors in 2026" (similar in length).

[0230] False query 2: "Price trend of aluminum alloy in the beverage can market in 2026".

[0231] False query 3: "Safety standards for magnesium alloys used in children's toys in 2026".

[0232] 2. The system will fill the actual query and the three pseudo queries into 1024 bytes each (with a space or random letter added at the end).

[0233] 3. The system will randomly sort the four requests, for example, in the order of: pseudo 2, real, pseudo 1, pseudo 3.

[0234] 4. Before each request is sent, the system waits for a random period of time (Poisson distribution, average interval 30 seconds, actual interval may be between 15-45 seconds).

[0235] 5. Four requests were received in the cloud, but the content alone could not distinguish which one represented the true intent. Even if an attacker could monitor the traffic, they could not infer the user's research direction based on time patterns or packet size.

[0236] Beneficial effects: Significantly improves the ability to resist side-channel analysis and protects the privacy of users' research fields.

[0237] Example 6: Intelligent Routing and Multi-Model Orchestration (Market Analysis Report Generation)

[0238] User input (via this application's gateway interface): Please write a market analysis report on 'Flying Wheels' and estimate sales for the next three years.

[0239] User preferences: Role = Product Manager, Cost Sensitivity = 0.2, Delay Sensitivity = 0.3, Accuracy Sensitivity = 0.5.

[0240] Processing flow:

[0241] 1. Intent deconstruction and security level mapping:

[0242] The physical "Flying Wheel" has been marked as L3 (private idea) by the user.

[0243] Subtask A: Text="Collect the latest automotive market data", does not contain L3 or L2 entities, full control level = S1, task type = data retrieval, network required = yes.

[0244] Subtask B: Text="Perform SWOT analysis on 'Flying Wheel'", contains L3 entities, security level = S3, task type = business reasoning, network required = no.

[0245] Subtask C: Text="Estimated sales for the next three years", does not contain L3 entities, but "flying wheel" should be used as contextual reference. The system determines that de-identification is required, security level = S2, task type = numerical calculation / prediction, network connection required = no.

[0246] 2. Routing decision:

[0247] Subtask A (S1, Retrieval): Select "Search Augmentation Model" (cost 0.01, latency 400ms, accuracy 85, supports network connectivity).

[0248] Subtask B (S3): Force routing to the local model (local SLM).

[0249] Subtask C (S2, Prediction): Candidate models are limited to those that support de-identified placeholders. GPT-4 supports this, Claude supports it, and local models also support it but with limited capabilities. Overall score: GPT-4 has an accuracy of 92, a cost of 0.03, and a latency of 800ms, resulting in a high score; therefore, GPT-4 is the preferred choice.

[0250] 3. De-identification and Query Restructuring:

[0251] Subtask A: Send the original query directly (no L2 or L3 entities).

[0252] Subtask B: Executed locally, without sending network requests.

[0253] Subtask C: Replace "Flying Wheel" with<ENT_001> The intended rewrite is: Based on the following market data, the forecast is...<ENT_001> Sales figures for the next three years. Validator passed.

[0254] 4. Scheduling and execution:

[0255] Subtasks A and C are independent and execute in parallel. Subtask B is independent of them and can also be executed in parallel.

[0256] Subtask A calls the Search Augmentation Model API to return global automotive market data for 2026.

[0257] Subtask B generates a SWOT analysis locally (based on sketch parameters in the local memory).

[0258] Subtask C calls the GPT-4 API and returns a sales forecast table.

[0259] 5. Integration:

[0260] Desensitization: Returning GPT-4 to the original...<ENT_001> Replace it with "Flying Wheel".

[0261] Fill in the three sections according to the report template (title, market overview, SWOT analysis, sales forecast, conclusion).

[0262] Use the local SLM polishing language to generate the final report.

[0263] 6. Output: The user receives a complete report. Throughout the process, the user did not manually select any models, and the L3 private entity "Flying Wheel" was not exposed to any external models.

[0264] Based on the same inventive concept, embodiments of this application also provide a privacy-preserving query system applied to an isolated computing environment with exclusive user control. This isolated computing environment supports calling cloud-based models and local models, such as... Figure 2 As shown, the system includes:

[0265] The query splitting module 10 is used to split the original query into several independent subtasks.

[0266] The determination module 20 is used to extract at least one entity contained in each of the subtasks and determine the privacy level of each entity; determine the security level of each subtask based on the highest level of the entity privacy level in each subtask; determine the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask; and determine the calling order of each query model based on the association relationship of each subtask.

[0267] The calling module 30 is used to call the query model matched by each of the subtasks based on the calling order.

[0268] The fusion module 40 is used to receive the return results of each of the query models, and merge the return results to obtain the answer to the original query.

[0269] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application, and are the system corresponding to the above privacy-protected query. All implementation methods in the above method embodiments are applicable to the embodiments of this device. For details on their specific functions and the resulting technical effects, please refer to the method embodiments section, which will not be repeated here.

[0270] The system also includes a local private knowledge structure, or private knowledge base. This private knowledge base is an encrypted storage system decoupled from any backend AI model, possessing the following characteristics: Persistence: All data (dialogue history, uploaded documents, user ideas, anonymized mapping tables, user preference configurations) is stored locally and is not lost upon device restart. Model Independence: A unified API is provided, allowing any local or cloud-based model to retrieve relevant knowledge through the query interface without requiring adaptation for any specific model. Manageability: Users can directly view, edit, and delete private entities (i.e., entities with an entity privacy level of L3), modify aliases, and merge duplicate entities through a graphical interface. Auditability: The system records which external requests each private entity was used for (time, target model, request ID), allowing users to trace the process. Portability: Supports exporting all private knowledge (including entity canonical names, aliases, dialogue history, and vector indexes) in a standardized JSON format. The exported data can be imported into another device or another backend model, enabling knowledge migration.

[0271] The data structure includes: a private entity table (shared with the anonymized mapping table, but additionally storing user editing tags); a dialogue history table: each record contains a session ID, timestamp, original query, anonymized query, model used, and response content (encrypted); a document table: the original content (encrypted) of uploaded documents (PDF, TXT, MD, etc.) and a chunked vector index; a user preference table: role tags (e.g., "Product Manager", "Researcher"), cost sensitivity (0-1), latency sensitivity (0-1), accuracy sensitivity (0-1), and a list of preferred models; and a vector index: using a local vector database (e.g., sqlite-vec or embedded chroma) to store the private entity canonical names and the embedded vectors of document chunks, supporting semantic retrieval.

[0272] The system can be deployed as a local gateway, a private cloud instance, or an intelligent agent agent, and all deployments implement the same core data processing logic.

[0273] Type A: Local gateway type.

[0274] The system is installed on the user's personal computer, laptop, or mobile device as a desktop application or system service. All data processing (semantic parsing, data masking, database storage, routing) is performed locally; only publicly accessible queries after data masking are sent over the network. This approach is suitable for individual users.

[0275] Type B: Cloud-based private instance type.

[0276] Users create a virtual machine or container instance on a public cloud platform (such as AWS, Alibaba Cloud, or Tencent Cloud) and install the system software described in this application within that instance. The instance runs in a Trusted Execution Environment (TEE, such as Intel SGX or AMDSEV), and the encryption key is kept solely by the user; the cloud platform operator cannot read the instance's memory or storage. Users can access the instance's API via the public internet or VPN. This approach is suitable for users who require higher computing performance or do not wish to run services locally, while still retaining data sovereignty.

[0277] Form C: Agent form.

[0278] The system described in this application is deployed as a plugin, middleware, or proxy server to intercept all outbound network requests from intelligent agents (such as AutoGPT). The intelligent agent treats this application as a "privacy proxy," and all external communications are processed through this application. This approach is suitable for scenarios where enterprises or individuals use intelligent agents to automate workflows.

[0279] When the system detects that the accessing client is an agent with autonomous planning and multi-step invocation capabilities (such as AutoGPT, BabyAGI, etc.), it automatically enters "zero-trust audit mode". Detection methods include: checking the User-Agent or custom fields (such as X-Agent-Type) in the HTTP request header. Behavioral pattern detection: initiating multiple different types of tool call requests within a short period (e.g., 10 seconds). In audit mode: all outbound requests (including API calls and tool calls) issued by the agent must first pass through the system's semantic decomposition and desensitization module. If a request is detected to contain a private entity with an entity privacy level of L2 (i.e., an undesensitized private entity), the system intercepts the request and displays a confirmation dialog box on the user interface, as shown in the example below: Agent 'AutoGPT' attempts to send the following request: Read file 'Project Plan.docx', which contains the private entity 'Project Plan' (entity privacy level L2). Allow? The user can choose to allow this time, deny this time, or always deny this type of request. If the user denies, the system returns an error response to the agent (e.g., "Request denied by user"), and the agent should adjust its execution plan. All interceptions and user decisions are logged in an audit log for users to review later. This model differs from traditional static access control (such as file system read permissions) in that it focuses on semantic analysis of outbound network requests, rather than simply controlling access to local resources.

[0280] Since L3 privacy-level entities have been forcibly assigned S3 security level and routed to the local model during the subtask splitting stage, they will not enter the outbound request process. Therefore, in audit mode, only L2 privacy-level entities that have not been de-identified are targeted.

[0281] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in any of the above-described privacy-preserving query method embodiments.

[0282] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0283] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0284] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A privacy-preserving query method applied to a user-exclusive, isolated computing environment, wherein the isolated computing environment supports calling cloud models and local models, characterized in that... The method includes: The original query is broken down into several independent subtasks; Extract at least one entity contained in each of the subtasks and determine the privacy level of each entity; determine the security level of each subtask based on the highest privacy level of the entity in each subtask; Based on the security level of each subtask, a query model matching each subtask is determined from the candidate cloud model set and the candidate local model set; and based on the association relationship of each subtask, the calling order of each query model is determined. Based on the aforementioned invocation order, the query model matched by each of the subtasks is invoked; The system receives the return results from each of the query models and merges them to obtain the answer to the original query.

2. The method according to claim 1, characterized in that, The step of determining the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask includes: Obtain user preference configuration information, as well as task information for each of the subtasks; the task information includes at least the task type and task complexity. Based on the security level of each subtask, the user preference configuration information, and the task information, a query model matching each subtask is determined from the candidate cloud model set and the candidate local model set.

3. The method according to claim 1, characterized in that, The query model that is invoked for matching each of the subtasks includes: Determine whether the query model matched by the subtask is a cloud model; If so, the target constraint of the original query is obtained, and the subtask is reconstructed based on the target constraint. The reconstructed subtask is then sent to the matching cloud model. If not, the subtask is sent directly to the matching local model.

4. The method according to claim 3, characterized in that, After determining whether the query model matched by the subtask is a cloud model, the method further includes: Determine whether the subtask includes an entity with a preset privacy level; the entity with the preset privacy level is an entity with de-identified information. If the subtask is included and the query model matched by the subtask is a cloud model, then the entity is reversibly de-identified, the subtask is reconstructed, and the de-identified and reconstructed subtask is sent to the matched cloud model.

5. The method according to claim 1, characterized in that, Before invoking the query model matched by each of the subtasks, the method further includes: Determine whether the query model matched by the subtask is a cloud model; If so, a security enhancement strategy is applied to the subtask before retransmission. The security enhancement strategy includes at least one of the following: traffic padding, time and size normalization, out-of-order delayed transmission, generalized reconstruction, embedded semantic noise, or generation of pseudo-task packages.

6. The method according to claim 1, characterized in that, Determining the privacy level of each entity includes: Each entity is matched against a locally stored private entity table. If a match is found, the corresponding entity is determined to be at the third level. Each entity is matched against the locally stored de-identification mapping table. If a match is successful, the corresponding entity is determined to be at the second level. Otherwise, the corresponding entity is designated as Level 1; the privacy levels of Level 1, Level 2, and Level 3 increase sequentially.

7. The method according to claim 6, characterized in that, The determination of the security level of each subtask based on the highest level of entity privacy in each subtask includes: If the highest level is the first level, then the security level of the corresponding subtask is determined to be the first level; If the highest level is the second level, then the security level of the corresponding subtask is determined to be the second level; If the highest level is the third level, then the security level of the corresponding subtask is determined to be the third level.

8. The method according to claim 7, characterized in that, The step of determining the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask includes: If the security level of the subtask is Level 1, then a matching query model is determined from the candidate cloud model set. If the security level of the subtask is Level 2, then a matching query model is determined from the cloud models that support de-identification processing in the candidate cloud model set. If the security level of the subtask is level three, then a matching query model is determined from the candidate local model set.

9. The method according to claim 6, characterized in that, The step of matching each entity with a locally stored private entity table, and determining the corresponding entity as a third-level entity if a match is successful, includes: Each entity is precisely matched with a private entity table stored locally. If the entity has a canonical name or alias in the private entity table, the corresponding entity is determined to be at the third level. If an exact match fails, the entity is converted into a vector, and the cosine similarity between the vector and all private entity canonical name vectors in the private entity table is calculated to obtain the maximum similarity. If the maximum similarity value is greater than a preset threshold, the corresponding entity is determined to be at the third level.

10. The method according to claim 1, characterized in that, The isolated computing environment includes one of the following: a user's local personal computing device, a cloud-based virtual private instance with which the user has exclusive control, or a container instance within a trusted execution environment.

11. A privacy-preserving query system applied to an isolated computing environment with exclusive user control, wherein the isolated computing environment supports calling cloud models and local models, characterized in that, The system includes: The query splitting module is used to split the original query into several independent subtasks; The determination module is used to extract at least one entity contained in each of the subtasks and determine the privacy level of each entity; determine the security level of each subtask based on the highest level of the entity privacy level in each subtask; determine the query model matching each subtask from the candidate cloud model set and the candidate local model set based on the security level of each subtask; and determine the calling order of each query model based on the association relationship of each subtask. The calling module is used to call the query model matched by each of the subtasks based on the calling order; The fusion module is used to receive the return results of each of the query models, and merge the return results to obtain the answer to the original query.

12. The system according to claim 11, characterized in that, The system can be deployed as a local gateway, a private instance in the cloud, or an intelligent agent agent.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 10.

Images