Vector library permission control method, system, device and medium for low-code retrieval

Abstract

The application discloses a vector library permission control method, system, device and medium for low-code retrieval, and belongs to the technical field of enterprise-level data security management. The technical problem to be solved by the application is how to realize role-granularity data visibility configuration, reduce the permission management threshold, improve the configuration efficiency, ensure data security, and adopt the technical scheme. The technical scheme is as follows: permission configuration: the access permission of a role and a vector library data is configured through a low-code visual interface, and a standardized permission rule is generated; dynamic permission injection: when a user initiates a retrieval request, the permission rule is analyzed in real time and the query statement is rewritten, permission filtering is realized, and it is ensured that the user can only access the data within the authorized range; conflict resolution: based on a multi-dimensional priority strategy, the optimal effective rule is automatically selected from the conflict rule to solve the strategy conflict problem when multiple role permissions are superimposed; and audit tracking: the user retrieval behavior and the permission change log are comprehensively recorded.

Description

Technical Field

[0001] This invention relates to the field of enterprise-level data security management technology, specifically to a low-code retrieval vector library access control method, system, device, and medium. Background Technology

[0002] Existing enterprise-level data access control systems suffer from issues such as coarse-grained access control, high configuration complexity, and a lack of dynamic permissions. Traditional permission models only support database / table-level permissions, making it difficult to meet the needs of collection or field-level access control within vector libraries. Furthermore, permission policy code must be manually written by developers, resulting in high configuration complexity and making it unsuitable for users of low-code platforms. Additionally, when roles change or data partitions are adjusted, permission rules cannot be synchronized to the vector retrieval engine in real time, leading to data access risks.

[0003] Therefore, how to achieve role-based granular data visibility configuration, reduce the threshold of permission management, improve configuration efficiency, and ensure data security are urgent technical problems to be solved. Summary of the Invention

[0004] The technical objective of this invention is to provide a low-code retrieval vector library access control method, system, device, and medium to address the issues of how to achieve role-based granular data visibility configuration, reduce the threshold for access management, improve configuration efficiency, and ensure data security.

[0005] The technical objective of this invention is achieved as follows: a low-code retrieval method for vector library access control, the specific method of which is as follows: Permission configuration: Configure access permissions for roles and vector library data through a low-code visual interface, generate standardized permission rules, and reduce configuration complexity; Dynamic permission injection: When a user initiates a search request, the permission rules are parsed in real time and the query statement is rewritten to implement permission filtering and ensure that the user can only access data within the authorized scope; Conflict resolution: Based on a multi-dimensional priority strategy, the optimal effective rule is automatically selected from conflicting rules to resolve policy conflicts when multiple role permissions overlap, ensuring the accuracy and consistency of permission management; Audit trail: Comprehensive recording of user search behavior and permission change logs to meet enterprise compliance audit needs and enhance data security.

[0006] As a preferred option, the permission configuration is as follows: In the __init__ method, three empty lists are automatically initialized: the role list, the dataset list, and the rule list. The role list stores all defined roles; the dataset list stores all managed datasets; and the rule list stores all created permission rules. Creating permission rules: Specific permission rules are established using the `create_rule` method. Permission rules include four core dimensions: role identifier, target dataset identifier, list of allowed fields, and dynamic conditions. The role identifier dimension specifies the user role to which the permission rule applies; the target dataset identifier dimension specifies the dataset to which the permission rule applies; the list of allowed fields is used to precisely control the data fields accessed by a role; and the dynamic conditions dimension is used to set filtering conditions for data access, achieving row-level permission control. Rule validation: When creating permission rules or importing permission rules in batches, the validate_rule method is used to check the validity of the rules. It checks whether the role specified in the permission rule has been registered in the role list. If the role does not exist, a role not found exception is thrown.

[0007] As a preferred method, dynamic permission injection is implemented as follows: Query preprocessing and dynamic permission injection: Before a user executes a query, the query statement is automatically modified based on the user's identity and permission rules to ensure that the user can only view the data they are authorized to access. Specifically: A DynamicPermissionInjector object is initialized to handle permission injection for structured data queries. The DynamicPermissionInjector object includes a rule loader and a query rewriter. The rule loader loads the corresponding data access rules from the database or configuration center based on the user's role. The query rewriter securely and correctly stitches the permission conditions into the original query statement. When user initiates a data query request original_query, the original_query is intercepted and handed over to the process_query method for processing. The permission rules are loaded and parsed, and all parsed, specific filter conditions (such as "department = 'Sales Department'", "security_level <= 3") are collected into a list permission_conditions. The original query statement original_query and the newly generated permission_conditions list are forwarded to query_rewriter. The query_rewriter analyzes the syntax structure of the original query and securely injects the permission conditions using an AND operation. Vector index permission optimization query: The VectorIndexOptimizer handles permission filtering for unstructured vector data. Specifically, it receives a query vector (query_vector) and permission conditions (permission_conditions), calls the prefilter_candidates method, and then calls _apply_permission_filters. _apply_permission_filters performs fast filtering directly on the vector data's metadata based on the permission_conditions. Each vector is stored with its associated department and security level attributes, generating a list of authorized vector IDs (filtered_ids). Users have access to all vectors in the filtered_ids list. After obtaining the filtered_ids list, an approximate nearest neighbor search (ANN algorithm, such as HNSW, IVF) is performed on the filtered vector set, searching within the filtered_ids subset and returning compliant search results. The approximate nearest neighbor search only finds the top-k results most similar to the query_vector among the allowed vectors.

[0008] More specifically, the loading and parsing permission rules are as follows: Loading rules: Based on the user's role, a set of predefined data filtering rules (user_rules) are loaded via rule_loader. The data filtering rules (user_rules) are used to define "who can see what data"; Parsing dynamic rules: The `_parse_rules` method is called to iterate through each rule and parse it to generate a list of permission conditions; The `query_rewriter` function injects permission conditions into the original query and returns the rewritten query statement. `_parse_rules(rules, user)` is a rule parser that iterates through all rules and calls `_resolve_dynamic_vars` to parse dynamic variables and generate a list of conditions. `_resolve_dynamic_vars(conditions, user)` is a dynamic variable parser that processes dynamic conditions in the form of `${user.department}`, extracting variable names (e.g., `department`), obtaining corresponding attribute values ​​from the user object, and generating an equivalent SQL expression (e.g., `department = 'Technical Department'`).

[0009] As a preferred approach, conflict resolution is as follows: Create a conflict resolution engine instance and receive a pre-defined set of priority rules; Receive the current set of user roles and the list of conflicting business rules to be adjudicated; Each conflict rule is scored as follows: Role hierarchy weight: The `_get_role_weight` method (depending on the `priority_rules` configuration) is called to calculate a base score, i.e., the role weight score, based on the role associated with the rule within the user role hierarchy; Business criticality bonus: The `_calculate_priority_score` method is used to check if the rule is marked as business critical. If the rule is marked as business critical, the `_get_role_weight` method is called to add extra weight to the corresponding rule, i.e., a criticality bonus; Calculate the final score: Final score = Role weight score + Criticality bonus; Sorting and Selection: Sort all rules in descending order of their overall score, select the rule with the highest score as the final rule to be executed, and return the applicable rule with the highest priority.

[0010] As a preferred option, the audit trail is as follows: The initialization of the anomaly detection system involves receiving the audit logger (audit_logger) and threshold configuration dictionary (threshold_config) as dependencies, and instantiating them as system properties to complete the initialization. The audit logger is used to collect user behavior data (such as operation time, data type, and operation object). The threshold configuration dictionary (threshold_config) is used to define the anomaly judgment thresholds for various behavioral indicators (such as maximum hourly query volume and daily limit on sensitive data access). The main behavior analysis method, analyze_behavior(user_actions), calculates a set of user behavior metrics based on the user behavior sequence user_actions (a structured record containing metadata such as timestamps, operation types, and data sensitivity markers), iterates through the user behavior metric set, compares it with the threshold configuration to generate a list of abnormal alerts, and returns formatted alert information. The behavior metric calculator _calculate_metrics(actions) generates a standard metric set, counts the total number of user-initiated query operations in the past hour, and counts the number of times users accessed data marked as sensitive. Anomaly detection: An alarm is triggered when the indicator value exceeds the corresponding threshold in the threshold_config dictionary. It supports parallel detection of multiple indicators and monitors multiple dimensions such as query frequency, sensitive data access and irregular operations.

[0011] A low-code retrieval vector library access control system, which implements the low-code retrieval vector library access control method described above; the system includes: The permission configuration center provides a low-code interface for configuring roles and data visibility rules, generating standardized permission rules and reducing configuration complexity. The dynamic permission injection engine is used to dynamically load user permission rules during the search process when a user initiates a search request, parse the permission rules in real time and rewrite the query statement to achieve permission filtering and ensure that users can only access data within the authorized scope. The conflict resolution engine is used to automatically select the optimal effective rule from conflict rules based on multi-dimensional priority strategies, so as to solve the policy conflict problem when multiple role permissions are superimposed, and ensure the accuracy and consistency of permission management. The audit trail module is used to comprehensively record user search behavior and permission change logs, meeting enterprise compliance audit needs and enhancing data security.

[0012] Preferred dynamic permission injection engines include: The dynamic permission injector is used to dynamically inject permission control conditions before user query execution, handling permission injection for structured data queries and achieving permission compliance transformation of query statements. The dynamic permission injector includes a rule loader and a query rewriter. The rule loader defines the association between roles and datasets, field-level permission control, and dynamic variable injection, and loads corresponding permission rules based on user roles. The query rewriter injects permission conditions into the original query, i.e., by dragging and dropping roles to associate them with datasets, selecting accessible fields, and using built-in condition templates to achieve dynamic variable injection. The vector index optimizer is designed for vector search scenarios, handling permission filtering of unstructured vector data to improve search efficiency and security. The optimizer includes a permission rule caching mechanism module and a vector index dynamic adjustment module. The permission rule caching mechanism module caches parsed permission rules, improving the efficiency of permission judgment and reducing system response time. The vector index dynamic adjustment module dynamically adjusts the vector index based on changes in permission rules to optimize retrieval performance and accuracy. The conflict resolution engine includes a conflict resolution and permission inheritance module and a policy priority configuration interface. The conflict resolution and permission inheritance module is used to define priority rules and resolve multi-level role inheritance and permission conflicts. The policy priority configuration interface provides a visual interface that allows enterprise administrators to customize policy priorities according to business needs and flexibly deal with complex permission conflict scenarios. The audit trail module includes an anomaly detection engine and an anomaly behavior warning engine. These engines analyze user search behavior and permission change history to automatically identify and warn of potential security risks or violations, thereby enhancing the enterprise's security protection capabilities. The anomaly behavior warning engine includes an audit log processor and a threshold configuration dictionary. The audit log processor collects user behavior data (such as operation time, data type, and operation object). The threshold configuration dictionary defines the anomaly judgment thresholds for various behavior indicators (such as the maximum number of queries per hour and the maximum number of times sensitive data can be accessed per day).

[0013] An electronic device includes: a memory and at least one processor; The memory contains computer programs; The at least one processor executes the computer program stored in the memory, causing the at least one processor to perform the vector library access control method for low-code retrieval as described above.

[0014] A computer-readable storage medium storing a computer program that can be executed by a processor to implement a vector library access control method for low-code retrieval as described above.

[0015] The low-code retrieval vector library access control method, system, device, and medium of the present invention have the following advantages: (i) Enterprise administrators of this invention can easily complete role-dataset permission configuration, reducing configuration complexity and improving configuration efficiency; (ii) This invention supports field-level permission control and dynamic variable injection, avoiding the risk of data leakage and achieving fine-grained control; (iii) After the permission rules of this invention are changed, they can be synchronized to all online search sessions in real time, so as to take effect in real time and ensure data security; (iv) Through a low-code visual configuration interface, enterprise administrators can easily set access permissions for roles and vector library data, support field-level permission control and dynamic variable injection, and achieve efficient and refined management of enterprise-level data; (v) This invention specifically involves the cross-integration of low-code development platform technology, vector database and semantic retrieval technology, realizing the deep integration of permission control model (RBAC / ABAC) and vectorized data retrieval, thereby realizing role-granular data visibility configuration, reducing the threshold of permission management, improving configuration efficiency and ensuring data security. Attached Figure Description

[0016] The invention will be further described below with reference to the accompanying drawings.

[0017] Appendix Figure 1 A schematic diagram of the structure of a vector library access control system for low-code retrieval; Appendix Figure 2 A flowchart illustrating the process of dynamic permission injection. Detailed Implementation

[0018] The low-code retrieval vector library permission control method, system, device, and medium of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. Example

[0019] This embodiment provides a low-code retrieval method for vector library access control, as detailed below: S1. Permission Configuration: Configure access permissions for roles and vector library data through a low-code visual interface, generate standardized permission rules, and reduce configuration complexity. S2. Dynamic permission injection: When a user initiates a search request, the permission rules are parsed in real time and the query statement is rewritten to implement permission filtering and ensure that the user can only access data within the authorized scope. S3. Conflict Resolution: Based on a multi-dimensional priority strategy, the optimal effective rule is automatically selected from the conflict rules to resolve the policy conflict problem when multiple role permissions are superimposed, ensuring the accuracy and consistency of permission management. S4. Audit Trail: Comprehensively records user search behavior and permission change logs to meet enterprise compliance audit needs and enhance data security.

[0020] The permission configuration in step S1 of this embodiment is as follows: S101. In the __init__ method, three empty lists are automatically initialized: the role list, the dataset list, and the rule list. The role list stores all defined roles; the dataset list stores all managed datasets; and the rule list stores all created permission rules. S102. Create Permission Rules: Specific permission rules are established using the `create_rule` method. Permission rules include four core dimensions: role identifier, target dataset identifier, list of allowed access fields, and dynamic conditions. The role identifier dimension specifies the user role to which the permission rule applies; the target dataset identifier dimension specifies the dataset to which the permission rule applies; the list of allowed access fields precisely controls the data fields accessed by each role; and the dynamic conditions dimension sets filtering conditions for data access, achieving row-level permission control. S103, Rule Validation: When creating a permission rule or importing permission rules in batches, the validate_rule method is used to check the validity of the rule. It checks whether the role specified in the permission rule has been registered in the role list. If the role does not exist, a role not found exception is thrown.

[0021] The key code is as follows: class PermissionConfigurator: def __init__(self): self.roles = [] self.datasets = [] self.rules = [] def create_rule(self, role, dataset, fields, conditions): rule = { "role": role, "dataset": dataset, "allowed_fields": fields, "dynamic_conditions": conditions } self.rules.append(rule) return rule def validate_rule(self, rule): if rule['role'] not in self.roles: raise ValueError("Role does not exist").

[0022] The dynamic permission injection in step S2 of this embodiment is as follows: S201. Query Preprocessing and Dynamic Permission Injection: Before a user executes a query, the query statement is automatically modified based on the user's identity and permission rules to ensure that the user can only view data they are authorized to access. Specifically: A DynamicPermissionInjector object is initialized to handle permission injection for structured data queries. The DynamicPermissionInjector object includes a rule loader and a query rewriter. The rule loader loads the corresponding data access rules from the database or configuration center based on the user's role. The query rewriter securely and correctly "stitches" the permission conditions into the original query statement. When user initiates a data query request original_query, the original_query request is intercepted and handed over to the process_query method for processing. The permission rules are loaded and parsed, and all parsed specific filtering conditions (such as "department = 'Sales Department'", "security_level <= ...) are processed. 3) Collect them into a list called permission_conditions; forward the original query statement original_query and the newly generated permission_conditions list to query_rewriter; query_rewriter is used to analyze the syntax structure of the original query and safely inject the permission conditions in an AND manner; S202. Permission-Optimized Query for Vector Index: Permission filtering for unstructured vector data is handled by VectorIndexOptimizer. Specifically, it receives a query vector (query_vector) and permission conditions (permission_conditions), calls the prefilter_candidates method, and then calls _apply_permission_filters. _apply_permission_filters performs fast filtering directly on the vector data's metadata based on the permission_conditions. Each vector is stored with its associated department and security level attributes, resulting in a list of authorized vector IDs (filtered_ids). Users have access to all vectors in the filtered_ids list. After obtaining the filtered_ids list, an approximate nearest neighbor search (ANN algorithm, such as HNSW, IVF) is performed on the filtered vector set. The search returns compliant search results within the filtered_ids subset. The approximate nearest neighbor search only finds the top-k results most similar to query_vector among the allowed vectors.

[0023] The loading and parsing permission rules in step S201 of this embodiment are as follows: ① Loading rules: Based on the user's role, a set of predefined data filtering rules (user_rules) are loaded through rule_loader. The data filtering rules (user_rules) are used to define "who can see what data"; ② Parse dynamic rules: Call the _parse_rules method to traverse each rule and parse the rule to generate a list of permission conditions; ③ The permission conditions are injected into the original query through query_rewriter, and the rewritten query statement is returned. _parse_rules(rules, user) is a rule parser that traverses all rules and calls _resolve_dynamic_vars to parse dynamic variables and generate a list of conditions. _resolve_dynamic_vars(conditions, user) is a dynamic variable parser that processes dynamic conditions in the form of ${user.department}, that is, extracts variable names (such as department), obtains the corresponding attribute values ​​from the user object, and generates an equivalent SQL expression (such as department = 'technical department').

[0024] The key code is as follows: # Example of Query Preprocessing Process class DynamicPermissionInjector: def __init__(self, rule_loader, query_rewriter): self.rule_loader = rule_loader self.query_rewriter = query_rewriter def process_query(self, user, original_query): user_rules = self.rule_loader.load_rules(user.roles) permission_conditions = self._parse_rules(user_rules, user) rewritten_query = self.query_rewriter.inject_conditions( original_query, permission_conditions ) return rewritten_query def _parse_rules(self, rules, user): conditions = [] for rule in rules: resolved_conditions = self._resolve_dynamic_vars( rule['dynamic_conditions'], user ) conditions.extend(resolved_conditions) return conditions def _resolve_dynamic_vars(self, conditions, user): resolved = [] for key, value in conditions.items(): if value.startswith("${user."): attr = value[7:-1] resolved.append(f"{key} = '{getattr(user, attr)}'") return resolved # Vector Index Optimization Example class VectorIndexOptimizer: def prefilter_candidates(self, query_vector, permission_conditions): # Filter vector sets based on permission conditions filtered_ids = self._apply_permission_filters(permission_conditions) # Perform approximate nearest neighbor search after filtering results = self._ann_search(query_vector, filtered_ids) return results def _apply_permission_filters(self, conditions): # Convert permission conditions into vector metadata filtering conditions # Return the list of authorized vector IDs Pass.

[0025] The conflict resolution in step S3 of this embodiment is as follows: S301. Create a conflict resolution engine instance and receive a preset set of priority rules; S302. Receive the current set of user roles and the list of conflicting business rules to be adjudicated; S303. Each conflicting rule is scored, specifically as follows: Role hierarchy weight: The `_get_role_weight` method (depending on the `priority_rules` configuration) is called to calculate the base score, i.e., the role weight score, based on the role associated with the rule within the user role system; Business criticality bonus: The `_calculate_priority_score` method is used to check if the rule is marked as business critical. If the rule is marked as business critical, the `_get_role_weight` method is called to add extra weight to the corresponding rule, i.e., a criticality bonus; Calculate the final score: Final score = Role weight score + Criticality bonus. S304, Sorting and Selection: Sort all rules in descending order of their overall score, select the rule with the highest score as the final execution rule, and return the applicable rule with the highest priority.

[0026] The key code is as follows: class ConflictResolutionEngine: def __init__(self, priority_rules): self.priority_rules = priority_rules def resolve(self, user_roles, conflicting_rules): scored_rules = [] for rule in conflicting_rules: score = self._calculate_priority_score(rule, user_roles) scored_rules.append((score, rule)) scored_rules.sort(key=lambda x: x[0], reverse=True) return scored_rules[0][1] def _calculate_priority_score(self, rule, user_roles): score = 0 # Bonus points based on role level role_weight = self._get_role_weight(rule['role'], user_roles) score += role_weight # Bonus points based on business criticality if rule.get('is_critical'): score += 10 Return score.

[0027] The audit trail in step S4 of this embodiment is as follows: S401. Initialization of the anomaly detection system: The system receives the audit logger (audit_logger) and threshold configuration dictionary (threshold_config) as dependencies, and instantiates them as system properties, thus completing the initialization of the anomaly detection system. The audit logger (audit_logger) is used to collect user behavior data (such as operation time, data type, and operation object). The threshold configuration dictionary (threshold_config) is used to define the anomaly judgment thresholds for various behavioral indicators (such as the maximum number of queries per hour and the maximum number of sensitive data accesses per day). S402. The main behavior analysis method analyze_behavior(user_actions) calculates a set of user behavior metrics based on the user behavior sequence user_actions (a structured record containing metadata such as timestamps, operation types, and data sensitivity markers), iterates through the user behavior metrics set, compares it with the threshold configuration to generate an abnormal alert list, and returns formatted alert information. S403. Generate a standard metric set using the behavior metric calculator _calculate_metrics(actions), count the total number of user-initiated query operations in the past hour, and count the number of times users accessed operations marked as sensitive data. S404, Anomaly Detection: An alarm is triggered when the indicator value exceeds the corresponding threshold in the threshold configuration dictionary threshold_config. It supports parallel detection of multiple indicators and monitors multiple dimensions such as query frequency, sensitive data access, and irregular operations.

[0028] The key code is as follows: # Example of abnormal behavior warning class AnomalyDetectionSystem: def __init__(self, audit_logger, threshold_config): self.audit_logger = audit_logger self.threshold_config = threshold_config def analyze_behavior(self, user_actions): # Calculate user behavior metrics metrics = self._calculate_metrics(user_actions) # Detecting anomalies based on thresholds alerts = [] for metric, value in metrics.items(): threshold = self.threshold_config.get(metric) if value > threshold: alerts.append(f"{metric} exception: {value} > {threshold}") return alerts def _calculate_metrics(self, actions): metrics = { " hourly_query_volume": len([a for a in actions if awithin_last_hour]), "sensitive_data_access_count": len([a for a in actions ifa.is_sensitive]), } Return metrics. Example

[0029] As attached Figure 1 As shown, this embodiment provides a low-code retrieval vector library access control system, which is used to implement the low-code retrieval vector library access control method as described in Embodiment 1; the system includes: The permission configuration center provides a low-code interface for configuring roles and data visibility rules, generating standardized permission rules and reducing configuration complexity. The dynamic permission injection engine is used to dynamically load user permission rules during the search process when a user initiates a search request, parse the permission rules in real time and rewrite the query statement to achieve permission filtering and ensure that users can only access data within the authorized scope. The conflict resolution engine is used to automatically select the optimal effective rule from conflict rules based on multi-dimensional priority strategies, so as to solve the policy conflict problem when multiple role permissions are superimposed, and ensure the accuracy and consistency of permission management. The audit trail module is used to comprehensively record user search behavior and permission change logs, meeting enterprise compliance audit needs and enhancing data security.

[0030] As attached Figure 2 As shown, the dynamic permission injection engine in this embodiment includes: The dynamic permission injector is used to dynamically inject permission control conditions before user query execution, handling permission injection for structured data queries and achieving permission compliance transformation of query statements. The dynamic permission injector includes a rule loader and a query rewriter. The rule loader defines the association between roles and datasets, field-level permission control, and dynamic variable injection, and loads corresponding permission rules based on user roles. The query rewriter injects permission conditions into the original query, i.e., by dragging and dropping roles to associate them with datasets, selecting accessible fields, and using built-in condition templates to achieve dynamic variable injection. The vector index optimizer is designed for vector search scenarios, handling permission filtering for unstructured vector data to improve search efficiency and security. The optimizer includes a permission rule caching mechanism module and a dynamic vector index adjustment module. The permission rule caching mechanism module caches parsed permission rules, improving the efficiency of permission judgment and reducing system response time. The dynamic vector index adjustment module dynamically adjusts the vector index based on changes in permission rules to optimize retrieval performance and accuracy.

[0031] The dynamic permission injection engine in this embodiment achieves full-scenario permission control from SQL queries to vector searches through a role-rule-condition linkage mechanism, which is suitable for intelligent search systems that require fine-grained data access control.

[0032] The conflict resolution engine in this embodiment includes a conflict resolution and permission inheritance module and a policy priority configuration interface. The conflict resolution and permission inheritance module is used to define priority rules to solve the problem of multi-level role inheritance and permission conflicts. The policy priority configuration interface is used to provide a visual interface, allowing enterprise administrators to customize policy priorities according to business needs and flexibly deal with complex permission conflict scenarios.

[0033] The design features of the conflict resolution engine in this embodiment are as follows: ① Dynamic priority mechanism: Achieve quantitative adjudication of conflict rules through a dual scoring dimension of role weight + key marker; ② Deterministic decision-making: The rule of taking the highest score after ranking ensures that the conflict resolution outcome is predictable and traceable; ③ Scalable design: priority_rules is a configurable parameter that supports adjusting priority strategies for different business scenarios.

[0034] The audit trail module in this embodiment includes an anomaly detection engine and an anomaly behavior warning engine. The former is used to automatically identify and warn of potential security risks or violations by analyzing user search behavior and permission change history, thereby improving the enterprise's security protection capabilities. The anomaly behavior warning engine includes an audit log processor and a threshold configuration dictionary. The audit log processor is used to collect user behavior data (such as operation time, data type, operation object, etc.). The threshold configuration dictionary is used to define the anomaly judgment thresholds for each behavior indicator (such as the maximum number of queries per hour, the maximum number of times sensitive data can be accessed per day, etc.).

[0035] The design features of the audit trail module in this embodiment are as follows: ① Dynamic threshold configuration: The detection threshold can be dynamically adjusted through external configuration files or interfaces to adapt to the security requirements of different business scenarios; ② The metrics are scalable: The _calculate_metrics method adopts a modular design, which makes it easy to add new behavioral analysis dimensions; ③ Audit log integration: Deeply coupled with the audit log system to ensure the integrity and traceability of behavioral data. Example

[0036] This embodiment also provides an electronic device, including: a memory and a processor; The memory stores the instructions executed by the computer. The processor executes computer execution instructions stored in the memory, causing the processor to execute the low-code retrieval vector library access control method in any embodiment of the present invention.

[0037] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.

[0038] Memory can be used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, memory can also include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart memory cards (SMC), secure digital cards (SD cards), flash memory cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices. Example

[0039] This embodiment also provides a computer-readable storage medium storing multiple instructions, which are loaded by a processor to cause the processor to execute the low-code retrieval vector library access control method in any embodiment of the present invention. Specifically, a system or apparatus equipped with a storage medium may be provided, on which software program code implementing the functions of any of the above embodiments is stored, and the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage medium.

[0040] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0041] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0042] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0043] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0044] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A low-code retrieval vector library access control method, characterized in that, The method is as follows: Permission configuration: Configure access permissions for roles and vector library data through a low-code visual interface, and generate standardized permission rules; Dynamic permission injection: When a user initiates a search request, the permission rules are parsed in real time and the query statement is rewritten to implement permission filtering and ensure that the user can only access data within the authorized scope; Conflict resolution: Based on a multi-dimensional priority strategy, the optimal effective rule is automatically selected from conflicting rules to resolve policy conflicts when multiple role permissions overlap; Audit trail: Comprehensive record of user search behavior and permission change logs.

2. The low-code retrieval vector library access control method according to claim 1, characterized in that, The specific permission configuration is as follows: In the __init__ method, three empty lists are automatically initialized: the role list, the dataset list, and the rule list. The role list stores all defined roles; the dataset list stores all managed datasets; and the rule list stores all created permission rules. Creating permission rules: Specific permission rules are established using the `create_rule` method. Permission rules include four core dimensions: role identifier, target dataset identifier, list of allowed fields, and dynamic conditions. The role identifier dimension specifies the user role to which the permission rule applies; the target dataset identifier dimension specifies the dataset to which the permission rule applies; the list of allowed fields is used to precisely control the data fields accessed by a role; and the dynamic conditions dimension is used to set filtering conditions for data access, achieving row-level permission control. Rule validation: When creating permission rules or importing permission rules in batches, the validate_rule method is used to check the validity of the rules. It checks whether the role specified in the permission rule has been registered in the role list. If the role does not exist, a role not found exception is thrown.

3. The low-code retrieval vector library access control method according to claim 1, characterized in that, Dynamic permission injection is implemented as follows: Query preprocessing and dynamic permission injection: Before a user executes a query, the query statement is automatically modified based on the user's identity and permission rules to ensure that the user can only view the data they are authorized to access. Specifically, a DynamicPermissionInjector object is initialized to handle permission injection for structured data queries. The DynamicPermissionInjector object includes a rule loader and a query rewriter. The rule loader loads the corresponding data access rules from the database or configuration center based on the user's role. The query rewriter securely and correctly "stitches" the permission conditions into the original query statement. When user initiates a data query request `original_query`, the `original_query` is intercepted and handed over to the `process_query` method for processing. The method loads and parses the permission rules, collecting all parsed and specific filter conditions into a list `permission_conditions`. The original query statement `original_query` and the newly generated list of `permission_conditions` are then forwarded to `query_rewriter`. `query_rewriter` analyzes the syntax structure of the original query and securely injects the permission conditions using an AND operation. Vector index permission optimization query: Permission filtering for unstructured vector data is handled by VectorIndexOptimizer. Specifically, it receives a query vector (query_vector) and permission conditions (permission_conditions), calls the prefilter_candidates method, and then calls _apply_permission_filters. _apply_permission_filters performs fast filtering directly on the vector data's metadata based on the permission_conditions. Each vector is stored with its associated department and security level attributes, generating a list of authorized vector IDs (filtered_ids). Vectors in the filtered_ids list are accessible to all users. After obtaining the filtered_ids list, an approximate nearest neighbor search is performed on the filtered vector set, searching within the filtered_ids subset and returning compliant search results. The approximate nearest neighbor search only finds the top-k results most similar to the query_vector among the allowed vectors.

4. The low-code retrieval vector library access control method according to claim 3, characterized in that, The specific rules for loading and parsing permissions are as follows: Loading rules: Based on the user's role, a set of predefined data filtering rules (user_rules) are loaded via rule_loader; Parsing dynamic rules: The `_parse_rules` method is called to iterate through each rule and parse it to generate a list of permission conditions; The `query_rewriter` function injects permission conditions into the original query and returns the rewritten query statement. `parse_rules(rules, user)` is a rule parser that iterates through all rules and calls `resolve_dynamic_vars` to parse dynamic variables and generate a list of conditions. `resolve_dynamic_vars(conditions, user)` is a dynamic variable parser that processes dynamic conditions, extracts variable names, retrieves corresponding attribute values ​​from the user object, and generates an equivalent SQL expression.

5. The low-code retrieval vector library access control method according to claim 1, characterized in that, The conflict resolution process is as follows: Create a conflict resolution engine instance and receive a pre-defined set of priority rules; Receive the current set of user roles and the list of conflicting business rules to be adjudicated; Each conflict rule is scored as follows: Role hierarchy weight: The `_get_role_weight` method is called to calculate the base score, i.e., the role weight score, based on the hierarchical position of the role associated with the rule in the user role system; Business criticality bonus: The `_calculate_priority_score` method is used to check whether the rule is marked as business critical. If the rule is marked as business critical, the `_get_role_weight` method is called to add extra weight to the corresponding rule, i.e., criticality bonus. Calculate the final score: Final score = Role weight score + Keyness bonus; Sorting and Selection: Sort all rules in descending order of their overall score, select the rule with the highest score as the final rule to be executed, and return the applicable rule with the highest priority.

6. The low-code retrieval vector library access control method according to claim 1, characterized in that, The audit trail is as follows: Initialization of the anomaly detection system: It receives the audit logger and threshold configuration dictionary as dependencies for dependency injection, and instantiates the audit logger and threshold configuration dictionary as system properties to complete the initialization of the anomaly detection system; among them, the audit logger is used to collect user behavior data; the threshold configuration dictionary is used to define the anomaly judgment thresholds for various behavior indicators; The main behavior analysis method, analyze_behavior(user_actions), calculates a set of user behavior metrics based on the user behavior sequence user_actions, iterates through the user behavior metrics set, compares them with the threshold configuration to generate a list of abnormal alerts, and returns formatted alert information. The behavior metric calculator _calculate_metrics(actions) generates a standard metric set, counts the total number of user-initiated query operations in the past hour, and counts the number of times users accessed data marked as sensitive. Anomaly detection: An alarm is triggered when the indicator value exceeds the corresponding threshold in the threshold_config dictionary. It supports parallel detection of multiple indicators and monitors multiple dimensions such as query frequency, sensitive data access and irregular operations.

7. A low-code retrieval vector library access control system, characterized in that, This system is used to implement the low-code retrieval vector library access control method as described in any one of claims 1 to 6; the system includes: The permission configuration center provides a low-code interface for configuring roles and data visibility rules, and generates standardized permission rules. The dynamic permission injection engine is used to dynamically load user permission rules during the search process when a user initiates a search request, parse the permission rules in real time and rewrite the query statement to achieve permission filtering and ensure that users can only access data within the authorized scope. The conflict resolution engine is used to automatically select the optimal effective rule from conflict rules based on a multi-dimensional priority strategy to resolve the policy conflict problem when multiple role permissions overlap. The audit trail module is used to comprehensively record user search behavior and permission change logs.

8. The low-code retrieval vector library access control system according to claim 7, characterized in that, Dynamic permission injection engines include: The dynamic permission injector is used to dynamically inject permission control conditions before user query execution, handling permission injection for structured data queries and achieving permission compliance transformation of query statements. The dynamic permission injector includes a rule loader and a query rewriter. The rule loader defines the association between roles and datasets, field-level permission control, and dynamic variable injection, and loads corresponding permission rules based on user roles. The query rewriter injects permission conditions into the original query, i.e., by dragging and dropping roles to associate them with datasets, selecting accessible fields, and using built-in condition templates to achieve dynamic variable injection. The vector index optimizer is designed for vector search scenarios, handling permission filtering of unstructured vector data to improve search efficiency and security. The optimizer includes a permission rule caching mechanism module and a vector index dynamic adjustment module. The permission rule caching mechanism module caches parsed permission rules, improving the efficiency of permission judgment and reducing system response time. The vector index dynamic adjustment module dynamically adjusts the vector index based on changes in permission rules to optimize retrieval performance and accuracy. The conflict resolution engine includes a conflict resolution and permission inheritance module and a policy priority configuration interface. The conflict resolution and permission inheritance module is used to define priority rules and resolve multi-level role inheritance and permission conflicts. The policy priority configuration interface provides a visual interface that allows enterprise administrators to customize policy priorities according to business needs and flexibly deal with complex permission conflict scenarios. The audit trail module includes an anomaly detection engine and an anomaly behavior warning engine. These engines analyze user search behavior and permission change history to automatically identify and warn of potential security risks or violations, thereby improving the enterprise's security protection capabilities. The anomaly behavior warning engine includes an audit log processor and a threshold configuration dictionary. The audit log processor is used to collect user behavior data, and the threshold configuration dictionary is used to define the anomaly judgment thresholds for each behavior indicator.

9. An electronic device, characterized in that, include: Memory and at least one processor; The memory contains computer programs; The at least one processor executes the computer program stored in the memory, causing the at least one processor to perform the low-code retrieval vector library access control method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that can be executed by a processor to implement the vector library access control method for low-code retrieval as described in any one of claims 1 to 6.

Images