Accounting file archiving path driving method

Abstract

This invention relates to the field of archival technology, specifically to a path-driven method for archiving accounting records. It includes the following steps: receiving a user's search intent expressed in natural language; extracting a rule set and path template through semantic parsing; establishing a virtual folder, including: querying a smart tag inverted index for each atomic condition in the rule set; performing a set operation on the query results of all atomic conditions according to the logical relationship defined in the rule set to obtain a hash set of data blocks for that rule set; reading the list of smart tag values ​​associated with each hash value in the hash set; assigning a virtual path string to each data block; and dynamically rendering the virtual path string into a browsable directory tree. This invention renders tree nodes as interactive directory tree components, enabling the method to dynamically generate a virtual folder view entirely based on the user's search intent, without moving or copying any physical data blocks.

Description

Technical Field

[0001] This invention relates to the field of archival technology, and more specifically, to a path-driven method for archiving accounting records. Background Technology

[0002] In records management, the core idea of ​​the archive path-driven method is to automatically map the metadata characteristics of records to the abstract path template in the storage system through a preset rule engine, thereby driving the archive operation.

[0003] Data blocks (i.e., electronic documents such as accounting vouchers, ledgers, and reports) are typically stored in a fixed format in a file system or object storage. To quickly locate specific data blocks, current technologies widely employ B+ trees as the underlying index structure. A B+ tree is a balanced multi-way search tree where all data records are stored in leaf nodes, with internal nodes storing only key-value pairs for navigation. When a user needs to retrieve data based on a metadata field (such as "voucher number," "year," or "account title"), the system uses the B+ tree index to search downwards from the root node, ultimately finding the corresponding data block's storage location in a leaf node.

[0004] However, once a B+ tree index is built based on a certain field, it's impossible to switch to other dimension combinations for retrieval without rebuilding the index. For example, if the current B+ tree is sorted by "voucher number," it's impossible to perform efficient range queries directly by the combination of "year + accounting subject," typically requiring multiple auxiliary indexes or a full table scan. More importantly, B+ trees can only provide a flat mapping from key to data block, and cannot directly generate the multi-level directory tree view that users expect (such as a hierarchical structure like "2024 / Finance Department / Accounting Vouchers"). Some systems attempt to simulate a directory tree by modifying the physical storage path of data blocks, but this operation will invalidate the B+ tree index, requiring synchronous index updates, which is costly and error-prone.

[0005] Therefore, how to achieve flexible dynamic directory organization while retaining the efficient query capabilities of B+ tree indexes has become an urgent problem to be solved in this field. Summary of the Invention

[0006] To address the above problems, the present invention aims to provide an accounting record archiving path-driven method, which includes the following steps:

[0007] Receive the user's search intent expressed in natural language, and extract the rule set and path template through semantic parsing;

[0008] Creating a virtual folder includes:

[0009] For each atomic condition in the rule set, a query is performed in the smart tag inverted index. The query results of all atomic conditions are then subjected to set operations according to the logical relationship defined in the rule set to obtain the data block hash set of the rule set.

[0010] For each hash value in the hash set, read the list of its associated smart tag values;

[0011] Each data block is assigned a virtual path string;

[0012] Dynamically render virtual path strings into a browsable directory tree.

[0013] As a further improvement to this technical solution, the step of extracting the rule set and path template through semantic parsing includes:

[0014] The system performs word segmentation and phrase boundary recognition on the natural language input by the user, dividing it into several independent conditional phrases and identifying possible directory structure description phrases.

[0015] Each conditional phrase is input into a pre-trained language model to obtain a semantic vector;

[0016] Based on the semantic vector of the conditional phrase and its position in the sentence, dependency relations, and surrounding conjunctions, it is determined whether each conditional phrase belongs to a first-level rule or a second-level rule; the first-level rule includes scope, time period, and major category limitation; the second-level rule includes attributes and operations.

[0017] For each condition phrase, the corresponding metadata field name is determined through field semantic mapping;

[0018] Each conditional phrase is compiled into an executable evaluation function;

[0019] Based on the connectors and negations between conditional phrases, multiple evaluation functions at the same level are combined into a logical expression tree. The conditional phrases of the first-level rules form a first-level logical tree, and the conditional phrases of the second-level rules form a second-level logical tree.

[0020] The attribute names in the directory structure description phrase are mapped to metadata field names through field semantic mapping, and a sequence of path template placeholders is generated in the order described by the directory structure description phrase.

[0021] As a further improvement to this technical solution, the intelligent tag inverted index is constructed in real time based on the evaluation results of the data block according to the search intent.

[0022] As a further improvement to this technical solution, the construction steps of the intelligent tag inverted index include:

[0023] Collect all atomic conditions in the rule set;

[0024] Create an empty dictionary;

[0025] For each atomic condition, create True and False keys in an empty dictionary. The initial value for each key is an empty set used to store the data block ID.

[0026] Get the complete set of data blocks;

[0027] The evaluation functions for all atomic conditions are applied sequentially to the contents of each data block in the entire dataset, yielding Boolean values.

[0028] If the evaluation result is True, then add the data block ID to the corresponding True key set;

[0029] If the evaluation result is False, then add the data block ID to the corresponding False key set;

[0030] After the traversal is complete, the smart tag inverted index is built.

[0031] As a further improvement to this technical solution, the step of performing set operations according to the logical relationships defined in the rule set includes:

[0032] Retrieve the set required for each leaf node of the first-level logic tree from the smart tag inverted index;

[0033] The set operations are performed on the selected set from bottom to top according to the operators in the first-level logic tree to obtain the first-level result set;

[0034] Retrieve the corresponding set from the smart tag inverted index based on the leaf nodes of the second-level logic tree;

[0035] Perform set operations from bottom to top according to the structure of the two-level logic tree to obtain a set of intermediate results for the second level;

[0036] Perform an intersection operation on the first-level result set and the second-level intermediate result set, and the resulting final set is used as the data block hash set of this rule set.

[0037] As a further improvement to this technical solution, the step of reading the list of associated smart tag values ​​includes:

[0038] Use the current data block ID as the key to initiate a point query to the label mapping table;

[0039] If the query finds a match, it returns a list containing all the smart tag values ​​for that data block.

[0040] If the query returns no match, an empty list is returned.

[0041] As a further improvement to this technical solution, the step of reading the list of associated smart tag values ​​includes:

[0042] For each data block ID and its corresponding tag list, the processing method is determined based on the next business requirement, including:

[0043] The next business requirement is to construct the display content of the virtual folder, which means merging the tag lists of multiple data blocks into a global list and removing duplicates;

[0044] The next business requirement is to further filter the data, so conditional judgments are performed on each tag list to filter out the data block IDs that meet the secondary conditions.

[0045] The next business requirement is to return the data to the upper layer request, so the ID of each data block and the list of tags are combined into a key-value pair, stored in the result set, and then output.

[0046] As a further improvement to this technical solution, the step of assigning a virtual path string to each data block includes:

[0047] Read the path template corresponding to the current rule set and break it down into an ordered list of placeholders;

[0048] For the current data block's list of smart label values, iterate through each label and determine its corresponding dimension through dimension attribution mapping;

[0049] Based on the order of the placeholders in the placeholder list, the values ​​of the corresponding dimensions are retrieved from the dimension attribution mapping in turn, and the placeholders in the path template are replaced to obtain the virtual path string;

[0050] Bind the generated virtual path string to the data block ID.

[0051] As a further improvement to this technical solution, the placeholders in the replacement path template include:

[0052] If the corresponding dimension has a value in the dimension attribution mapping, then replace it with that value itself;

[0053] If the corresponding dimension is missing in the dimension attribution mapping, the default value is used.

[0054] As a further improvement to this technical solution, the step of dynamically rendering the virtual path string into a browsable directory tree includes:

[0055] Collect the virtual path strings corresponding to all data blocks;

[0056] For each virtual path string, split it into a list of fragments by the delimiter, and insert all the fragment lists as a trie;

[0057] Starting from the root node, the process is recursively repeated, with each node becoming a folder node, eventually resulting in a multi-branch tree;

[0058] Render tree nodes as interactive components.

[0059] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0060] By leveraging the efficient data location capabilities of B+ tree indexes, an intelligent tag inverted index is constructed and set operations are performed according to the rule set. At the same time, virtual path strings are generated based on path templates and inserted into a trie to form a multi-branch tree. The tree nodes are then rendered as interactive directory tree components, enabling the method to dynamically generate virtual folder views that are entirely based on the user's search intent without moving or copying any physical data blocks.

[0061] In this way, users only need to express their intent in natural language, which can be automatically parsed into a set of rules and a path template. Then, the B+ tree index is used to quickly filter out candidate data blocks, and the intelligent tag inverted table is used to complete the combination calculation of multi-dimensional conditions, which greatly reduces the overhead of scanning line by line, thereby achieving millisecond-level retrieval response in hundreds of millions of data blocks. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of the steps of the accounting record archiving path-driven method of the present invention;

[0063] Figure 2 This is a schematic diagram illustrating the steps for creating a virtual folder according to the present invention;

[0064] Figure 3 This is a schematic diagram of the steps for extracting the rule set and path template according to the present invention;

[0065] Figure 4 This is a schematic diagram of the steps for constructing the intelligent tag inverted index according to the present invention;

[0066] Figure 5 This is a schematic diagram of the set operation steps according to the logical relationship defined by the rule set in this invention.

[0067] Figure 6 This is a schematic diagram of the steps for reading the smart tag value list according to the present invention;

[0068] Figure 7 This is a schematic diagram of the process for allocating virtual path strings according to the present invention;

[0069] Figure 8 This is a schematic diagram illustrating the steps of dynamically rendering a virtual path string into a directory tree according to the present invention. Detailed Implementation

[0070] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0071] Based on B+ tree indexes, existing systems can quickly locate a set of data blocks that satisfy a single field condition. For example, to query all data blocks where "year = 2024", the system can directly traverse the leaf node linked list using the B+ tree index on the year field to obtain the storage location of all matches. When multiple dimensions need to be combined for querying, a common approach is to create multiple single-field B+ tree indexes and then merge them using index intersection or Bloom filters; or to create composite B+ tree indexes, but the field order of composite indexes limits query flexibility.

[0072] The purpose of this invention is not to replace the B+ tree, but to leverage its efficient data location capabilities to build a flexible virtual directory organization layer on top of it. This layer generates a user intent-driven virtual directory tree through intelligent tag inverted indexes and logical tree set operations, without changing the actual storage location of data blocks or interfering with the structure of the B+ tree index. In specific implementation, a set of intelligent tags (e.g., "Year: 2024", "Department: Finance Department", "Voucher Type: Accounting Voucher") is pre-assigned to each data block, but these tags are only stored as metadata and do not affect the physical location of the data block. When a user inputs a natural language query, the rule set and path template are parsed, and then an intelligent tag inverted index is built based on the atomic conditions in the rules. During the construction of the inverted index, if a B+ tree index for the corresponding field (e.g., "Year") has already been established in the metadata table of the data block, the set of data block IDs that meet the conditions can be quickly obtained directly using this index, avoiding the need to evaluate all data blocks one by one. For example, when the atomic condition is "Year = 2024", all leaf nodes are located through the B+ tree index of the year field to collect the data block IDs, with an overhead of only [missing information]. (in: This represents the asymptotic upper bound of the algorithm's execution time, i.e., the trend of runtime increase as the data size grows. For example, Indicates time and It is proportional to the logarithm; The total number of all data blocks, in the context of accounting records, is the total number of entries for all vouchers or data records in the metadata table; The number of data blocks required to satisfy the current atomic conditions is far lower than that of a full table scan. For tag fields that do not support separate indexes (such as "credential type"), the evaluation is performed by sequentially scanning the metadata table or by utilizing the tag inverted index itself. However, since the candidate set has been significantly narrowed down by indexing, the overall efficiency is still acceptable.

[0073] After obtaining the smart tag inverted index, set operations (intersection, union, complement) are performed from bottom to top according to the parsed logical expression tree (e.g., "Year=2024 AND Department=Finance Department AND Voucher Type=Accounting Voucher") to obtain the final set of data block IDs that meet all conditions. Then, based on the smart tag list and path template for each data block (e.g., " / Year / Department / Voucher Type"), virtual path strings (e.g., " / 2024 / Finance Department / Accounting Voucher") are generated. These strings serve only as logical identifiers and are completely unrelated to the actual storage path of the data block. Finally, all virtual path strings are inserted into a trie (prefix tree) and rendered as a front-end tree component. When a user clicks on any folder, all data block IDs under that path are displayed, and the storage location of the data block is directly located through the underlying B+ tree index to read the file content.

[0074] Therefore, it is evident that the implementation of this invention relies entirely on the B+ tree index to accelerate data block filtering, without ever moving or renaming data blocks or altering the structure of the B+ tree. On the contrary, the rapid positioning capability of the B+ tree is one of the prerequisites for the efficient construction of the inverted index in this invention. Those skilled in the art will understand that the existence of the B+ tree index allows this invention to achieve efficient multi-dimensional filtering without maintaining an additional complex index structure, simply by utilizing existing indexes.

[0075] In the relationship between B+ tree indexes and storage layers, a data block refers to the smallest I / O unit in disk or memory (typically 4KB, 8KB, or 16KB), which is the basic unit for actual reading and writing in the storage system. Each data block can contain multiple voucher records, which are organized within the block as fixed-length or variable-length linked lists.

[0076] Figure 1 The steps of an accounting record archiving path-driven method according to an embodiment of the present invention are shown. Figure 2 The steps for creating a virtual folder using this method are shown in the attached image. Figure 1 The steps of this method include:

[0077] S100: Receive the user's search intent expressed in natural language, and extract the rule set and path template through semantic parsing.

[0078] In step S100, the retrieval intent refers to the user's search target for specific data expressed through natural language (such as spoken language or text). It is not a simple list of keywords, but an abstraction of a query intent with semantic associations. For example, if a user says "find all accounting vouchers from the company's finance department in 2024," the retrieval intent is "to locate the set of data blocks that meet the constraints of year, department, and voucher type." After semantic parsing, this intent is transformed into a structured rule set (specific conditions such as year = 2024, department = finance department, voucher type = accounting voucher) and a path template (i.e., which indexes or inverted tables the system should prioritize using when executing the query to efficiently obtain the result set). The methods for obtaining the natural language expression include one or more of the following:

[0079] Direct text input, which means that users manually type natural language query strings in the search box or input interface;

[0080] Voice input to text means that the user speaks a query through the microphone, the speech recognition module (ASR) converts the acoustic signal into text, and then sends it to the semantic parsing process;

[0081] Conversational interaction refers to users expressing complex intentions through chatbots or intelligent assistants in a multi-turn dialogue format. For example, the system first asks, "Which year's data do you want to query?", and the user answers, "2024." The system then asks, "Any other conditions?", and the user adds, "Finance Department." Each round of input is accumulated and merged to form a complete search intention.

[0082] The query description in the file or document, that is, the file uploaded by the user containing search conditions (such as an Excel template or instruction document), from which the query requirements described in natural language are extracted; for example, if the file says "I need to find all data of accounting vouchers in the Finance Department in 2024", it will be parsed as a natural language string.

[0083] The core purpose of these acquisition methods is to transform users' unstructured language descriptions into precise machine-executable instructions, thereby driving the subsequent index matching and inverted index construction process. Different acquisition methods vary in input quality, interaction complexity, and fault tolerance requirements for semantic parsing, but they all ultimately converge on the same semantic parsing engine to complete the conversion from natural language to rule sets and path templates.

[0084] The aforementioned specific data refers to the specific archival records or statistical results that a user ultimately hopes to obtain in their natural language search intent. Essentially, it is the concrete representation of the search target at the data level, including but not limited to the following types:

[0085] A single or multiple voucher records, such as a specific original voucher, accounting voucher, or review voucher that a user wants to find, including complete field content such as its number, date, amount, summary, and account;

[0086] A set of data blocks that meet certain conditions. A user query may hit multiple data blocks, and each data block contains a batch of records that are stored consecutively or logically related. In this case, specific data refers to these data blocks and the set of records within them.

[0087] Aggregate statistical results. For example, if a user asks "How many accounting vouchers did the finance department have in 2024?", the specific information is not a detailed breakdown of each voucher, but rather a statistical value such as a count or summation.

[0088] For the document or file itself, if the user wants to download the original electronic file (such as a PDF scan), the specific data refers to the location identifier and complete data content of the file object in storage.

[0089] S200, Create a virtual folder.

[0090] The process of creating a virtual folder is essentially a dynamic generation of a logical view driven by an index, without involving the movement or copying of any physical data blocks. After semantic parsing of the user's search intent, a set of explicit rules is obtained. For example, the rule set might include conditions such as year equal to 2024, department equal to finance department, voucher type equal to expense report, and amount greater than 1000 yuan. First, using a B+ tree index, all data blocks that might contain records matching the conditions are quickly located based on the primary key conditions. These data blocks have fixed physical locations on disk; they are simply marked as candidates. Next, each candidate data block is loaded into memory, and each record within it is compared one by one against the remaining fields in the rule set, such as whether the amount is greater than 1000 yuan. After filtering, only records that fully meet all conditions are selected. Crucially, the actual content of these records is not copied; only a pointer to each record in the original data block is recorded—the data block identifier plus the offset within the block. All these pointers are organized into a temporary index table, stored in memory, and sometimes written to a temporary table in a lightweight database. This temporary index table is the skeleton of the virtual folder; it's essentially a list of references to the original data and doesn't contain the data itself. The browser's file presentation layer (such as a network distributed file system interface or a custom file browser) maps this temporary index table to a visual directory tree structure. The folder hierarchy that the user sees, such as each file under "Expense Reimbursement Bills," is actually an entry in this index table. When the user clicks on a file, the corresponding pointer directly reads the record's content from the original data block and returns it to the user. Throughout the entire process, the data block and its internal records are never moved; only logical associations are established at the index layer through pointers.

[0091] In other words, the folders and files that users see in the virtual folder are not the actual directory structure on the physical disk, but a virtual view constructed in real time from the query result set. Just like when a query is performed on a table in a database, the returned result set logically forms a new table, but this new table doesn't store actual data; it's just a mapping of rows and columns. This relies on two layers of mapping: First, semantic parsing transforms natural language into a set of rules that computers can understand—this step is equivalent to defining the projection conditions; second, it uses indexes to quickly find all data blocks that meet the conditions, and then constructs a pointer list in memory—this list is the projection result. Even when sharing this virtual folder among different users, the pointer list is not copied. Instead, by sharing the rule set, each user re-executes the same projection operation in their own memory, thus obtaining a consistent view. This rule-based recalculation method ensures that data blocks always remain in their original locations, and any user's operation will not change the physical storage.

[0092] The disappearance mechanism of virtual folders relies on strict lifecycle management. Each virtual folder is bound to a user session, and a mapping from session identifiers to temporary index table pointers is stored in a hash table in memory. When a user actively closes a query view, the session times out (e.g., 30 minutes of inactivity), or a new query overwrites the old results, the corresponding mapping is immediately removed from the hash table, and the memory occupied by the temporary index table is released. Since the temporary index table itself does not contain data, but is only a list of references, the release operation is merely a memory reclamation action, requiring constant-time operation. The data blocks and records within them remain unchanged throughout the process, so the destruction of a virtual folder has zero impact on the original physical data. This is precisely what distinguishes it from traditional folder systems: if a traditional system wants to organize multiple files into a new directory, it either needs to create hard links (which adds metadata entries to the file system) or copy the data (which incurs huge input / output overhead). Virtual folders, on the other hand, neither add metadata nor copy data; the process is purely done at the memory index layer.

[0093] See Figure 2 The steps to create a virtual folder include:

[0094] S210. For each atomic condition in the rule set, query the smart tag inverted index, and perform set operations on the query results of all atomic conditions according to the logical relationship defined in the rule set to obtain the data block hash set of the rule set.

[0095] The core of this step is to retrieve the set of data block IDs corresponding to each atomic condition from the smart tag inverted index, and then perform set operations on these sets according to the logical expression tree (determined by the logical relationships in the rule set), ultimately obtaining the set of data block IDs that fully satisfies the search intent. The smart tag inverted index is a temporary dictionary structure that is built in real-time during query processing. Specifically, it first parses all atomic conditions in the rule set (e.g., "Year = 2024", "Department = Finance Department"), with each atomic condition corresponding to an evaluation function. The system creates a dictionary entry containing True and False keys for each atomic condition, initially with empty sets. Then, it iterates through all data blocks (or the candidate set narrowed down using a B+ tree index), sequentially executing the evaluation function for each atomic condition for each data block, and adding the data block ID to the True or False set of the corresponding atomic condition based on the evaluation result. In this way, the smart tag inverted index contains the positive result set (True) and the negative result set (False) for each atomic condition. Next, set operations are performed from bottom to top according to the structure of the logical expression tree: for example, for the expression "(Year=2024 AND Department=Finance Department) OR Voucher Type=Accounting Voucher", the intersection of the True set for Year=2024 and the True set for Department=Finance Department is taken to obtain an intermediate result, and then the union of this intermediate result with the True set for Voucher Type=Accounting Voucher is taken. If the logical expression contains NOT (negation word), the complement operation is performed using the False set of the corresponding atomic condition (i.e., the entire set minus the True set). The final set of data block IDs is the data block hash set. It is important to note that the construction process of the smart tag inverted table can make full use of the existing B+ tree index: for indexed fields (such as Year), all data block IDs that meet the conditions can be obtained directly through the index without traversing the entire set, greatly improving efficiency; for fields without indexes, only metadata or tag content can be scanned sequentially, but since the index has already significantly narrowed the candidate set, the overhead is still acceptable.

[0096] S220. For each hash value in the hash set, read the list of smart tag values ​​associated with it.

[0097] Based on the result set obtained in step S210, the preset metadata tags are extracted for each data block. The smart tag value list is a set of tags pre-stored for each data block. For example, the data block with ID 1001 might have a tag list like: {"Year: 2024", "Department: Finance Department", "Voucher Type: Accounting Voucher"}. This tag data is typically stored in a separate tag mapping table (such as a key-value database or in-memory hash table), with the data block ID as the key and the tag list as the value. In practice, each ID in the data block hash set is traversed, and a point query is initiated to the tag mapping table. If the query matches, all smart tag values ​​for that data block are returned; otherwise, an empty list is returned. The purpose of this step is to provide raw tag data for the subsequent generation of virtual path strings. Furthermore, depending on the next business requirement, it may be necessary to deduplicate, filter, or construct a key-value pair structure for the tag list. For example, if a directory tree needs to be constructed later, the tag value lists of all data blocks are merged and deduplicated to obtain a global dimension value set; if further filtering is needed, only tag entries that satisfy the quadratic condition are retained.

[0098] S230, Each data block is assigned a virtual path string.

[0099] The virtual path string is the logical path of a data block presented on the user interface, and its style is determined by the path template. The path template is extracted from the user's natural language parsing, such as " / year / department / voucher type". The system first breaks down the path template into an ordered list of placeholders, such as ["year", "department", "voucher type"]. Then, for each data block, each tag in its smart tag value list needs to be categorized by dimension affiliation mapping. Dimension affiliation mapping is a predefined rule, for example, the tag "year: 2024" belongs to the "year" dimension, and "department: finance department" belongs to the "department" dimension. The system traverses the tag list and constructs a dimension-to-value mapping dictionary (e.g., {"year": "2024", "department": "finance department", "voucher type": "accounting voucher"}). Next, according to the order of the placeholder list, the values ​​of the corresponding dimensions are retrieved from this mapping dictionary and replaced with the placeholders in the path template in turn. If a dimension is missing in the mapping, a default value (such as "unknown" or "other") is used. Finally, a virtual path string like " / 2024 / finance department / accounting voucher" is obtained. This string is completely unrelated to the actual physical storage path of the data block; it is purely a logical organizational identifier. After generation, the virtual path string needs to be bound to the data block ID so that a mapping from the directory node to the underlying data block can be established during subsequent rendering.

[0100] S240. Dynamically render the virtual path string into a browsable directory tree.

[0101] All virtual path strings generated in step S230 are organized into a tree structure and displayed as interactive folders and files in the front end or user interface. The specific implementation uses a trie (prefix tree) algorithm. The system collects all virtual path strings corresponding to data blocks (e.g., " / 2024 / Finance Department / Accounting Vouchers", " / 2024 / Finance Department / Other Vouchers", etc.), and splits each string into a list of fragments using the path separator " / ", for example, ["2024", "Finance Department", "Accounting Vouchers"]. Then, all fragment lists are inserted as paths into the trie: starting from the root node, for each fragment, if it already exists in the child nodes of the current node, it continues along that node; otherwise, a new node is created. The final trie has each path from the root node to the leaf node corresponding to a virtual directory level. Each leaf node can be associated with one or more data block IDs (because multiple data blocks may have the exact same virtual path). During rendering, each node of the trie is rendered as a folder icon, and the list of data blocks or files under that path can be displayed below the leaf node. Front-end components (such as tree controls) dynamically generate expandable and clickable directory structures based on a trie structure. When a user clicks on a folder, the system filters out the data block IDs whose paths begin with that prefix from all data blocks based on the path prefix corresponding to that node, and then uses a B+ tree index to locate the specific file for the user to access. At this point, the construction and presentation of the virtual folders are complete.

[0102] Figure 3 The steps for extracting the rule set and path template in one embodiment are shown below. Figure 3 The steps for extracting the rule set and path template through semantic parsing include:

[0103] S110. Perform word segmentation and phrase boundary recognition on the natural language input by the user, divide it into several independent conditional phrases, and identify possible directory structure description phrases.

[0104] The core objective of step S110 is to split a string of consecutive Chinese characters or words into semantically self-consistent independent units, while accurately distinguishing between two types of phrases, namely conditional phrases (indicating constraint conditions) and directory structure description phrases (indicating display levels). These two tasks need to be completed within a unified framework because the two types of phrases may appear alternately, and the boundary definition depends on semantic and syntactic features. A commonly used implementation scheme is the sequence annotation method based on a pre-trained language model (such as BERT), combined with rule post-processing. Specifically, the input sentence is preprocessed into a character sequence (a word sequence obtained after Chinese word segmentation can also be used, but the character level is more sensitive to boundaries). The label system adopts the BIO mode, but two additional entity categories are added: COND (conditional phrase) and DIR (directory description phrase). For example, the labels are defined as: B-COND and I-COND represent the start and inside of a conditional phrase; B-DIR and I-DIR represent the start and inside of a directory description phrase; the remaining characters are marked as O. The result output by the model assigns a label to each character, and then a complete conditional phrase is obtained by merging consecutive B-COND + I-COND segments. Similarly, B-DIR + I-DIR is merged to obtain a directory description phrase. This model usually uses BERT-Chinese or RoBERTa-wwm-ext as the encoder, followed by a linear layer and a CRF layer (conditional random field) to enhance the constraint of label transfer (for example, B-COND cannot be directly followed by I-DIR). The training data requires a large number of manually annotated real queries. For example, for the sentence "Find all the accounting vouchers of the finance department of the company in 2024 and display them by year / department / voucher type", the annotation result should be: "找" O, "出" O, "202" B-COND, "4" I-COND, "年" I-COND, "公" O, "司" O, "所" O, "有" O, "财" B-COND, "务" I-COND, "部" I-COND, "的" O, "会" B-COND, "计" I-COND, "凭" I-COND, "证" I-COND, "," O, "按" B-DIR, "年" I-DIR, "份" I-DIR, " / " I-DIR, "部" I-DIR, "门" I-DIR, " / " I-DIR, "凭" I-DIR, "证" I-DIR, "类" I-DIR, "型" I-DIR, "显" O, "示" O. Here, "2024年" is marked as a conditional phrase (but the actual semantics is "year = 2024"), "财务部" is also a conditional phrase, and "会计凭证" is the third conditional phrase; "年份 / 部门 / 凭证类型" is marked as a directory description phrase. Note that for phrases indicating a scope such as "公司所有" (such as "company = all" or "scope = all"), they are usually classified as conditional phrases, but for simplicity, they can be marked as B-COND, and "公司" and "所有" are merged into one phrase. The amount of data required for model training is about tens of thousands of items to cover common sentence patterns.During the prediction phase, the complete sentence is input into the model to obtain a label sequence. Then, the model scans from left to right based on the label sequence: whenever a B-COND or B-DIR is encountered, a segment is recorded until the next B-* or O label is encountered, thus extracting all phrases. Furthermore, it is necessary to reconstruct the original text (word sequence) of the phrases from the original sentence, rather than simply relying on the label concatenation output by the model, as spaces or special characters may exist.

[0105] However, sequence labeling alone may not be able to perfectly handle complex long phrases or nested cases. Therefore, post-processing rules are needed for correction. For example, if the identified conditional phrase contains conjunctions such as "and" or "and," and these conjunctions actually connect two different conditions, further splitting is required. The processing method is to check whether each extracted conditional phrase contains an independent field-value pair pattern (such as detecting the equals sign "=" or a space-separated "field + value" structure). If it contains such a pattern and there is a conjunction in between (such as "year=2024 and department=finance department"), then it is split into two independent conditional phrases at that conjunction: "year=2024" and "department=finance department."

[0106] Optionally, when labeling training data, such connections can be used as boundaries, directly labeling two B-CONDs with the word in between labeled as O. However, since users may write "Year 2024 Department Finance Department" consecutively without connecting words, such cases still need to be segmented using rules.

[0107] Optionally, when a conditional phrase contains parallel structures, it should be split into multiple phrases. Meanwhile, for negative words such as "not" or "except," which are usually appended before or after a conditional phrase (e.g., "the department is not the finance department"), should "not" be separately labeled as part of that conditional phrase? It is recommended that "not" be handled separately in step S110: when a negative word is detected, it should be removed from the conditional phrase and associated with a separate "negation identifier" for subsequent conditional phrases, or the negative word and the conditional phrase should be labeled together as a whole (e.g., "not the finance department" as a conditional phrase, with the negation parsed during subsequent logic tree construction).

[0108] Optionally, "not the finance department" can be treated as a single conditional phrase (label B-COND) during annotation, and then converted to NOT in subsequent step S160 based on the negative words it contains. However, it is necessary to ensure that such phrases can be correctly identified, and the training data needs to include such samples.

[0109] For identifying directory structure description phrases, in addition to sequence labeling, their internal structure needs to be processed separately. This is because directory descriptions typically contain fixed delimiters (such as " / ", "、", or spaces), and their order is important. Once the model identifies a complete directory description phrase (e.g., "by year / department / voucher type"), a list of attribute names needs to be extracted from it. Specifically, a simple regular expression or rule-based splitting method is used to break the phrase into multiple segments according to the delimiters, and then interference words (such as "by", "of", "directory", etc.) are removed from each segment. For example, the phrase "display by year / department / voucher type" yields a list ["year", "department", "voucher type"] after regular expression extraction. If the directory description phrase uses Chinese delimiters (such as "year, department, voucher type"), they are also separated by commas or pauses. To improve robustness, a stop word list (such as "by", "of", "display", "archive", "directory") can be pre-built and removed before extraction. The output of this step is an ordered list of attribute names, used for field semantic mapping in subsequent step S170.

[0110] Step S110 outputs a list of phrases in string form (each phrase is a string) and a list of possible directory attribute names (also a list of strings). These strings are directly used as input to step S120, fed into a pre-trained language model to obtain semantic vectors. Simultaneously, the original strings of the conditional phrases are also used for field semantic mapping in step S140 (requiring the parsing of field names and values). Therefore, step S110 must maintain the original format of the phrases (e.g., "year=2024"), without losing the internal equal signs and numerical values. Furthermore, the positional information of conjunctions and negations is not explicitly extracted in step S110, but is left for further analysis from the original input sentence in step S160.

[0111] Optionally, during sequence labeling in step S110, in addition to conditional phrases and directory description phrases, conjunctions and negation words are also identified as independent entities (such as B-AND, I-AND, B-OR, I-OR, B-NOT). Thus, step S110 not only outputs a list of phrases but also a sequential event stream containing phrases and their logical connections (conjunctions, negation words). Subsequent step S160 directly uses this stream to construct a logical expression tree without rescanning the original text. This is the most compact implementation. Therefore, it is recommended to expand the labeling system: add CONN (conjunction) labels (such as "and", "or") and NEG (negation) labels (such as "not", "except"). In this way, the sequence labeling model outputs all semantic units simultaneously, completing segmentation and relation extraction in one step. For example, in the sentence "Find the vouchers for 2024 that are not from the finance department", "and" is labeled as B-CONN, and "not" is labeled as B-NEG. During post-processing, all entities are collected in sequence: the conditional phrase "year=2024", the conjunction "and", the negation "not", and the conditional phrase "department=finance department" (but in reality, it should be the core phrase "department=finance department" + negation, or the phrase following "not" can be processed as a whole; here, it is preferable to bind "not" with the following phrase into a conditional phrase with negation, which is simpler). The negation word and the immediately following conditional phrase are merged into a single entity (labeled B-COND_NEG) according to rules. Then, the entity type is checked during the logic tree construction.

[0112] S120. Each conditional phrase is input into a pre-trained language model to obtain a semantic vector.

[0113] After segmentation in step S110, we obtain a list of conditional phrases, such as "Year = 2024" and "Department = Finance Department". Although these phrases are in text form, in subsequent step S130, it is necessary to determine whether they belong to a first-level rule or a second-level rule, and in step S140, to map the field names (such as "Year") to the canonical fields in the system metadata. If only string matching is used, it is impossible to handle synonyms ("Year" and "Year") or subtle variations in expression. Therefore, step S120 needs to convert these phrases into numerical vectors that computers can use for semantic comparison, that is, semantic vectors.

[0114] A pre-trained language model (taking BERT Chinese model as an example) is a deep neural network that can map natural language text of arbitrary length into a fixed-dimensional vector. Its core structure is the Transformer encoder, which will be explained below according to the process of data from input to output.

[0115] First, the input conditional phrase "year=2024" is segmented into several tokens by a word segmenter (based on sub-words), and a special token [CLS] is automatically inserted at the beginning and [SEP] at the end. Assuming the segmentation result is: [CLS], year, year, =, 2024, [SEP], a total of 6 tokens, let's call them... Each token corresponds to an integer number, and an initial word embedding vector is obtained by looking up a table. Additionally, to distinguish tokens at different positions, positional embeddings are added; since there is only one sentence, the segment embeddings are all zero. These three embedding vectors are added element-wise to obtain the input matrix:

[0116] ;

[0117] In the formula, This is the length of the current input sequence, which is 6 in this case. This is the hidden layer dimension of the model, which is 768 for BERT-base; It is The matrix, each row corresponds to a word embedding vector of a token, which is obtained directly from the pre-trained word embedding table by using the token ID, and represents the most basic semantic information of the token; Too The matrix, with each row corresponding to a fixed code for that position in the sequence, tells the network in this way that "year" appears in the 2nd position, "2024" appears in the 5th position, etc., so that the self-attention can perceive the order; It is a segment embedding. Since there is only one phrase here, the segment embeddings of all tokens are the same zero vector, so it can be ignored.

[0118] Obtain the initial matrix Then, it is fed into a multi-layer Transformer encoder. Each layer consists of a multi-head self-attention sublayer and a feedforward neural network sublayer, and each sublayer is followed by residual connections and layer normalization. Let's look at the self-attention sublayer first.

[0119] For ease of explanation, let's first consider a single-head attention mechanism (actually multi-head, but the principle is the same). First, the input... The query matrix is ​​obtained through three different linear transformations. Key matrix Sum matrix :

[0120] , , ;

[0121] In the formula, It is the query weight matrix, which maps the input vector to a lower dimension ( The space is used to calculate the level of attention each token pays to other tokens; It is a key-weight matrix, which also maps the input to... The dimension is used to perform a dot product operation with the query; It is a value weight matrix that maps the input to The dimension is used to provide specific content information when performing the final weighted summation; It is the dimension of each attention head, and the calculation formula is: , It is the number of attention heads (in BERT-base). ,therefore ).

[0122] Next, we calculate the attention score matrix:

[0123] ;

[0124] In the formula, It is The matrix, the first Line 1 The elements of the column represent the first... The query vector of the first token and the first token The dot product of the key vectors of the tokens; the larger the dot product value, the more significant the tagged value. The more attention you pay to the token, the better. Each token. Divide by This is for scaling purposes, to prevent the dot product result from becoming too large and causing the gradient to vanish in the subsequent softmax function, thus making the model training more stable.

[0125] Then, each row of this matrix (i.e., the attention score of each token to all other tokens) is normalized using softmax to obtain the attention weight matrix:

[0126] ;

[0127] In the formula, Represents the first in the fractional matrix Line 1 Column elements, It is an exponential function. After softmax, the... The sum of all elements in a row is 1, and the value of each element is between 0 and 1, indicating the row number. The token is assigned to the first Attention weight of each token; It is a summation index.

[0128] Finally, the value matrix is ​​weighted and summed using the normalized weights to obtain the output of the current head:

[0129]

[0130] The The line is the first A new representation of each token is created by fusing the value vectors of all tokens according to attention weights. This process allows each token to "see" other tokens in the sequence, thereby capturing contextual dependencies.

[0131] The actual model uses multi-head attention, which involves repeating the above process. Each time (using a different one) , , ),get indivual The output of is then concatenated into a single . The matrix, then through a linear projection matrix To merge:

[0132] ;

[0133] In the formula, It's a splicing operation. It is the first Output of the head; It is a learnable parameter matrix whose function is to merge multi-head information back into the matrix. 3D space. Among them... ( From 1 to ) indicates the first The output of each attention head, and the index of the last head is (Right now ). Here It is a variable (representing the total number of attention heads, for example, 12). Therefore, symbolically speaking, and They are all just different instances of the same symbol system; the former is a general index, and the latter is the last value.

[0134] Next, residual connections and layer normalization are performed:

[0135] ;

[0136] In the formula, "It is a residual connection that adds the original input to the attention output, so that the gradient can flow more smoothly through the deep network and avoid degradation problems; It's layer normalization, which applies to each token. The vectors are standardized independently, and then a learnable scaling and translation are applied. The specific formula is as follows:

[0137] ;

[0138] In the formula, It is a vector of a certain token; It is the average value of all components of the vector; It is the variance of the vector; A very small positive number (e.g.) ), to prevent the denominator from being zero; and These are trainable parameters used to scale and offset the normalized values, respectively, enabling the model to recover the necessary expressive power.

[0139] After the attention sub-layer, the data enters the feedforward neural network sub-layer. This sub-layer operates independently on the vector of each token, using two fully connected layers with a ReLU activation function in between.

[0140] ;

[0141] In the formula, It is the weight matrix of the first linear layer. It is the intermediate dimension of the feedforward network, usually set to... (i.e., 3072); It is the bias vector of the first linear layer; It is an element-wise ReLU activation function that truncates all negative numbers to 0, increasing the nonlinearity of the network; It is the weight matrix of the second linear layer, which maps the intermediate representation back to... dimension; It is the bias vector of the second linear layer.

[0142] Similarly, residual connections and layer normalization are also used here:

[0143] ;

[0144] This completes one Transformer encoding layer. BERT-base has 12 such layers, and the output of each layer is... The matrix is ​​used as the input for the next layer. After all 12 layers, the output matrix of the final layer is finally obtained. At this point, we take the first row of the matrix (i.e., the vector corresponding to the [CLS] token) as the semantic vector of the entire conditional phrase, denoted as... The reason for choosing the output at the [CLS] position is that BERT is trained during pre-training to represent the semantics of the entire input sequence using a vector at the [CLS] position. This vector contains the contextual information of all tokens and the relationships between words.

[0145] This obtained semantic vector Its uses in subsequent steps are as follows:

[0146] In step S130, it is concatenated with additional features such as the position number of the phrase in the original sentence and the type of adjacent conjunctions, and then fed into a fully connected layer. After passing through softmax, the probability of whether the phrase belongs to a first-level rule or a second-level rule is output.

[0147] In step S140, all system metadata fields (such as "Year", "Department", and "Voucher Type") also have their respective semantic vectors pre-calculated using the same BERT model (usually only the [CLS] vector of the field name is taken), and then the semantic vectors are calculated. Cosine similarity with each field vector:

[0148] ;

[0149] In the formula, "Indicates inner product, This represents the Euclidean norm of the vector. The field name with the highest similarity is selected as the canonical field corresponding to the phrase. Since semantic vectors contain synonym relationships (e.g., "year" and "year" are very close in the vector space), this process can naturally complete semantic mapping without manually maintaining a thesaurus.

[0150] S130. Using the semantic vector of the conditional phrase and its position in the sentence, dependency relations, and surrounding conjunctions, determine whether each conditional phrase belongs to a first-level rule or a second-level rule; where first-level rules include scope, time period, and major category limitations; and second-level rules include attributes and operations.

[0151] In step S130, each condition phrase generated in step S120 is determined to be either a first-level rule or a second-level rule. First-level rules refer to those conditions that can be directly located using a B+ tree. They describe the overall distribution characteristics of the data in the storage structure and do not involve checking each record within each data block. Second-level rules, on the other hand, require access to the actual content of the data block and perform pattern matching, numerical operations, or logical judgments on specific records or field values. Therefore, they must be executed after reading the data rows.

[0152] When a conditional expression matches an equality or range comparison of an index key, a B+ tree index can quickly locate the page range that meets the condition, thus skipping a large number of irrelevant data blocks. However, not all filtering conditions can be converted into index scans. For example, substring matching on a field, regular expressions, comparisons of numerical calculation results, or logical combinations between multiple fields must be completed after reading the actual data. Therefore, we can divide the conditions into two levels, including:

[0153] Level 1 rules utilize indexes to perform coarse-grained filtering, minimizing the number of data blocks that need to be accessed;

[0154] Secondary rules perform fine-grained filtering within the data blocks selected by primary rules, ensuring that the final result fully matches the user's query semantics.

[0155] The following examples illustrate how first-level rules can be directly obtained using a B+ tree, and why second-level rules need to access the data block content.

[0156] Example 1 of Level 1 rule:

[0157] The user's condition phrase is "year ≥ 2020". Assume the database has built a B+ tree index on the "year" field. The leaf nodes of the B+ tree are arranged in ascending order of year, each leaf node corresponding to a data page range and storing the minimum and maximum years of all records in that page. When the engine receives "year ≥ 2020", it can quickly locate the first leaf node containing "year ≥ 2020" using a binary search on the B+ tree. Then, it scans subsequent nodes sequentially along the linked list of leaf nodes until it encounters a year exceeding the upper limit (which is not explicitly defined). During this process, the engine only needs to read the index node and a small number of leaf nodes containing the target data (and their corresponding data pages), completely avoiding the need to examine data blocks containing "year < 2020". Similarly, "time period restrictions" such as "date between 2024-01-01 and 2024-01-31" can also be directly located using the B+ tree index on the time field.

[0158] Example 2 of Level 1 rule:

[0159] The user's condition phrase is "Department = Finance Department". If there is a B+ tree index on the "Department" field (which typically supports equality queries), the engine can search for the key value "Finance Department" in the B+ tree. Because B+ trees support equality searches, they can immediately find all leaf nodes storing "Finance Department" records and read the corresponding data pages. This approach also avoids scanning the entire table. It's important to note that even if the number of possible values ​​for the "Department" field is small (e.g., only 10 departments), the B+ tree can still accurately hit the target using the index without accessing data pages from other departments.

[0160] Example of secondary rule 1:

[0161] The user condition phrase is "name contains 'engineering'". Although the name field may be indexed, the operation here is "contains" rather than exact match or prefix match. For a Chinese database, a B+ tree index can only support prefix match (such as "Zhang%") or equality match; substring match ("%engineering%") cannot utilize the orderliness of the B+ tree because "engineering" may appear anywhere in the string and the index cannot skip records that do not contain the substring. Therefore, the engine must first narrow down the data block range through the primary rule (if any, such as "year ≥ 2020"), and then read the "name" field line by line in each remaining data block for substring match. This process requires accessing the actual content of the data block, that is, the row storage of each record.

[0162] Example of secondary rule 2:

[0163] The user condition phrase is "(amount * 1.1) > ......

[0164] In step S130, based on the semantic vector of the condition phrase, its position, dependency relationship, and surrounding conjunctions in the sentence, determine whether each condition phrase belongs to the primary rule or the secondary rule. Specifically, in step S120, a semantic vector has been generated for each condition phrase, and this vector encodes the semantics of the phrase. In step S140, we will match it with the semantic vector of each canonical field in the metadata to bind a specific field name (such as "year", "name", "amount") to the phrase. The information attached to this field name includes: whether the field is indexed, the index type (B+ tree, hash, etc.), and the data type of the field (numeric, string, date, etc.). With this metadata information, we can initially judge that: if there is a B+ tree index on the field and the operator of the phrase belongs to standard comparison operations such as "=", ">", "<", "≥", "≤", "BETWEEN", etc., then this phrase is very likely to belong to the primary rule.

[0165] However, relying solely on field index information is insufficient; it's also necessary to consider the syntactic position and context of the phrase to eliminate ambiguity. For example, in the phrase "year ≥ 2020," "year" is the subject, and "≥ 2020" is the predicate. Dependency relations tell us that the core of this phrase is a "field-comparison operation-value" structure, where the operator is "≥," which is a standard comparison. In contrast, in "name contains 'engineering'," the dependency relation corresponding to the operator "contains" is typically "verb-complement" or "preposition-object," which cannot be mapped to the standard comparison symbols in a B+ tree. Therefore, through dependency relation resolution, we can identify the type of operator and classify it as an "operation" rather than a "range." Similarly, "major category constraints" usually manifest as equality comparisons (field = constant), and the set of values ​​for that field is small (e.g., enumeration types). In this case, even without an index, it is often classified as a first-level rule because the database system can directly locate the relevant data page using dictionary information in the metadata (similar to the idea of ​​bitmap indexes). However, even without an index, equality comparisons can be quickly located by leveraging the sequential nature of the B+ tree (if an index is created).

[0166] Surrounding conjunctions can also provide clues: if a phrase is preceded by conjunctions such as "and" or "simultaneously," it indicates that the two phrases are parallel, but this does not change the nature of the individual phrases. However, if the conjunction is "or," the two phrases may belong to different levels, in which case the entire "or" clause needs to be broken down and judged separately. More importantly, surrounding conjunctions can reveal the logical combination relationship between phrases, which helps determine the execution order of rules in subsequent steps. Typically, first-level rules (index scan) are executed first, followed by second-level rules (row-by-row filtering) on ​​the result set of the first-level rules.

[0167] Furthermore, the position of phrases in the original query statement is also valuable: phrases appearing before the WHERE clause are more likely to indicate scope limitations, while those appearing later are more likely to indicate specific attribute conditions. However, this is not absolute; the more reliable indicators are the matching results between the semantic vector and metadata fields, as well as the operator types derived from dependency parsing.

[0168] In summary, the judgment logic of step S130 can be summarized as follows: For each conditional phrase, firstly, determine the associated field and operator type through semantic vectors. If the field has a B+ tree index and the operator is a standard comparison (such as =, ≥, BETWEEN), it is marked as a first-level rule; otherwise, it is marked as a second-level rule. Then, combine dependency relations and join words to verify consistency, and finally output the rule level of each phrase. The two-level rule setting enables the database query engine to first use the index to quickly cut out most of the irrelevant data, and then perform precise filtering within the remaining small range, thereby maintaining excellent query performance under large data volumes.

[0169] S140. For each condition phrase, determine its corresponding metadata field name through field semantic mapping.

[0170] In step S140, each conditional phrase extracted in step S120 (e.g., "year", "date", "department", "name containing 'engineering'") is mapped to the actual metadata field names stored in the database (e.g., publish_year, create_date, dept_name, user_name). Since the database's metadata field names are predefined by the designer and are typically short, standardized, or abbreviated, the conditional phrases used by the user in their query come from the natural language semantic space, and there is no direct word-for-word correspondence between the two. For example, if a user queries "find articles published after 2020", the conditional phrase is "after 2020", and the associated field concept is "publication year". However, the metadata might only have the field name "publish_year", or even split it into two fields: year and month. If a direct string matching is performed, "year" and "publish_year" will not be the same; semantic understanding is necessary to establish the association. Only after this mapping is completed can we know which column, data type, and index the "year" the user refers to specifically correspond to, and thus decide whether a B+ tree can be used for first-level rule filtering. In other words, field semantic mapping is the core bridge connecting natural language and database structure in the entire query understanding process.

[0171] Optionally, each conditional phrase and each metadata field (field name and its annotations and descriptions) is encoded into a fixed-dimensional semantic vector, and then the cosine similarity between the vectors is calculated. The field with the highest similarity is selected as the mapping result. Specifically:

[0172] For each field in the database, collect the field name (e.g., publish_year) and field comments or Chinese descriptions (e.g., "the year the article was published"). Concatenate these descriptive texts (e.g., "publish_year") and input them into a pre-trained Chinese language model (e.g., BERT-wwm or RoBERTa-zh). Take the vector output at the [CLS] position as the semantic vector for that field. If the database has no comments, you can use only the field names, but the names are often English abbreviations and the semantics are not intuitive. Therefore, it is recommended to maintain an additional list of field descriptions during system maintenance.

[0173] For each conditional phrase generated in step S120 (typically the core component of the phrase, such as "year"), its vector is extracted using the same pre-trained model. Note that only the part of the phrase representing the "field concept" is extracted here, not the operator or value. For example, for "year ≥ 2020", we only encode the "year"; for "name contains 'project'", we encode the "name". Preferably, the core of the condition phrase is usually a structure such as "noun (field concept) + operator + value", or "operator + value + noun". Step S130 has already analyzed the phrase, from which field concept words can be extracted.

[0174] For each conditional phrase, calculate the cosine similarity with each of the metadata field vectors:

[0175] ;

[0176] In the formula, This is the semantic vector extracted from the conditional phrase; For the first The semantic vector of each field; during matching, for the same condition phrase We need to work with all The similarity is calculated from the field vectors to select the most matching field. This represents the total number of fields in the database. To avoid false matches, a threshold (e.g., 0.6) needs to be set. Mapping results below this threshold require additional manual review or downgrading. Furthermore, if multiple fields have very close similarities, a domain-specific thesaurus can be used for secondary verification. For example, a mapping table of common business terms and field names can be collected (e.g., {"Year", "Published Year", "Publication Year"} → publish_year). When vector matching cannot clearly distinguish between them, a thesaurus can be used for precise matching.

[0177] Before vector matching, the semantics of the phrase are expanded using surrounding connectives and dependency relations. For example, for "edited date was yesterday," the dependency relations show that "date" is modified by "edit," so the phrase can be expanded to "edited date" before encoding, making the semantic vector closer to modify_date than create_date. Similarly, if words like "publish" or "create" appear around it, it tends to be publish_date.

[0178] S150. Compile each conditional phrase into an executable evaluation function.

[0179] After the field semantic mapping is completed in step S140, the metadata field names corresponding to each conditional phrase are obtained. However, the operators and values contained in the conditional phrase itself (such as "≥2020" and "contains 'engineering'") are still text-based expressions and cannot be directly understood and calculated by the database engine. Therefore, the task of step S150 is to "compile" these text-based conditional phrases into executable evaluation functions so that data can be judged according to the logic of these functions in memory or at the index level.

[0180] It should be noted that the query execution engine (whether it is a SQL engine or a custom filtering framework) only accepts deterministic and callable code logic, rather than natural language descriptions. After semantic parsing and field mapping, the original conditional phrase is essentially an "assertion": asserting that the value of a certain field must satisfy a certain constraint. Transforming this assertion into an executable function body (such as a lambda expression, a function pointer, a piece of Python code, or an expression tree) can be embedded into the query plan in a unified manner. In addition, static optimizations can be performed during the compilation process. For example, "year ≥ 2020" can be transformed into a parameter for an index range query without comparing line by line at runtime; or "name contains 'engineering'" can be transformed into a substring matching function and it is determined that this function belongs to a secondary rule and is only executed on the results after index filtering.

[0181] The specific form of the evaluation function depends on the underlying implementation architecture. Suppose we are using a Python interpreter or a SQL-like execution framework, then the evaluation function can be a callable object that accepts a single record (or a record dictionary) as a parameter and returns a boolean value. For example, for the primary rule "year ≥ 2020", the compiled evaluation function might be:

[0182] ;

[0183] However, in actual execution, this function will not be called one by one for judgment, but will be transformed into an index scan predicate: the engine will use the B+ tree to find all the leaf nodes where publish_year >= 2020 and directly return the corresponding record set. Therefore, for the primary rule, the compilation process is actually a "translation" process that translates the conditional phrase into the conditional parameters of the index scan without generating a truly line-by-line call function. For the secondary rule, such as "name contains 'engineering'", the compiled function is a real line-by-line judgment:

[0184] \text{eval\_func}(record) = \text{"engineering" in record.\text{user\_name}};

[0185] This function will be called repeatedly in subsequent steps to perform substring matching operations on each record filtered by the first-level rules.

[0186] During the query plan execution phase, multiple conditions need to be evaluated sequentially or in a nested structure. If each condition is an independent function, they can be combined (using logical AND, OR, and NOT operations) to form a composite evaluation function, thereby efficiently filtering data. Furthermore, since the condition phrases are mapped to specific fields, the internal logic of the evaluation function can directly access the value of that field, avoiding secondary mapping of field names.

[0187] The specific usage is divided into two phases. The first phase is the compilation phase: step S150 generates a corresponding evaluation function for each condition phrase, and simultaneously records the rule level (first-level rule or second-level rule) to which the function belongs, as well as the associated field names and index information. This information is stored in a rule list. The second phase is the execution phase: the query engine first traverses all first-level rules, transforms them into index scan conditions, and loads a set of candidate records (usually a set of data pages) that meet the conditions from the database. Then, for each candidate record, the evaluation functions of the second-level rules are executed one by one in order or by priority. Only records in which all second-level functions return True are retained. Throughout the process, the functions of the first-level rules are never called one by one, but are transformed into index parameters; the functions of the second-level rules are called explicitly. This design enables the compilation of evaluation functions to not only realize the transformation from natural language to machine logic, but also implicitly includes performance optimization strategies, separating out conditions that can utilize the index and avoiding a full scan of large datasets.

[0188] For example, suppose there are two conditional phrases: "Year ≥ 2020" (Level 1 rule) and "Name contains 'Engineering'" (Level 2 rule). In step S150, the former is compiled into an index range predicate (parameter: Year ≥ 2020), and the latter is compiled into a function lambdar: "Engineering"inr.user_name. During execution, the engine first uses the Level 1 rule to find all data pages with a year ≥ 2020, then calls the Level 2 evaluation function on each record in these pages, ultimately obtaining the records that satisfy "Name contains 'Engineering'". Thus, the entire query understanding and execution chain moves from natural language to executable code, completing a full mapping from semantics to computation.

[0189] S160. Based on the connectors and negations between conditional phrases, multiple evaluation functions at the same level are combined into a logical expression tree. The conditional phrases of the first-level rules form a first-level logical tree, and the conditional phrases of the second-level rules form a second-level logical tree.

[0190] Step S160 combines the logical relationships between multiple conditions (connectors such as "AND", "OR", "NOT", and the precedence imposed by parentheses) to form a structured logical expression tree. Step S150 only translates a single condition into an executable function, but queries typically contain combinations of multiple conditions, such as "year ≥ 2020 AND (department = 'Engineering Department' or name contains 'Zhang')". Without combination, the system cannot correctly determine whether the conditions are AND or OR, nor can it handle negation and nested relationships.

[0191] A logical expression tree is a tree-like data structure where each non-leaf node represents a logical operator (AND, OR, NOT), and each leaf node represents a pre-compiled evaluation function (i.e., the output of step S150). The tree structure reflects the logical hierarchy between the original conditional phrases; for example, conditions within parentheses are at a deeper overall depth. This allows the execution engine to compute Boolean results by post-order traversal of the tree, or to directly translate first-level rules into index operations.

[0192] To fully utilize the index and avoid the overhead of row-by-row scanning, step S160 categorizes all conditions according to their rule level (first-level or second-level rule) determined after field mapping in step S140. First-level rule conditions (such as indexable numerical comparisons and string prefix matching) form a first-level logical tree; second-level rule conditions (such as containment rules, regular expressions, and user-defined functions that must be evaluated row-by-row) form a second-level logical tree. Both trees are logically equivalent to the complete logical expression of the original query, but they are independent of each other. For example, the original query contains three conditions: A (first-level rule), B (second-level rule), and C (second-level rule), with the logical expression "A AND (B OR C)".

[0193] In practice, the logic tree should retain its original structure. However, since first-level and second-level conditions cannot be mixed in the same tree (because they are executed differently), the original tree needs to be split into two subtrees. Specifically, the original logic tree is traversed, keeping first-level rule nodes in the first-level tree and second-level rule nodes in the second-level tree, while keeping the logical operators between them unchanged.

[0194] Optionally, the original logic tree can be completely copied, but the first-level condition nodes can be replaced with Boolean constants (such as True), while the second-level condition nodes are retained, thus constructing a logic tree that is only executed on the second-level tree; simultaneously, the second-level condition nodes can be replaced with True to construct the first-level tree. The result is that all leaf nodes in the first-level tree are first-level rules, and the internal operators remain the original logical operators; all leaf nodes in the second-level tree are second-level rules, and the internal operators remain unchanged. The two trees are independent, but logical equivalence is guaranteed by "executing the first-level tree filter first, then executing the second-level tree on the result." For example, in the original query "A AND (B OR C)", A is the first level, and B and C are the second level. Then the first-level tree is "A AND (True OR True)", which simplifies to A; the second-level tree is "True AND (B OR C)", which is B OR C. During execution, A is first used to obtain the candidate set from a full table scan, and then each candidate in the candidate set is evaluated (B OR C). Note that the AND logic is correctly decomposed here: subsequent steps must perform a secondary tree on the candidate set, and the implicit AND relationship between the two still holds.

[0195] In the execution plan, the first-level logical tree is transformed into index filtering conditions. For example, if a leaf node A in the first-level tree is "year ≥ 2020", its parent node might be AND or OR. If the root of the first-level tree is AND, all leaf conditions are merged into a single composite index range; if it is OR, it is decomposed into multiple ranges for index merging (e.g., UniON). Based on the structure of the first-level tree, the system generates corresponding index scan predicates and directly loads the candidate record set that matches the first-level tree from the disk or memory index. This set is usually significantly reduced.

[0196] The second-level logic tree is used by calling the evaluation function of each candidate record in the candidate record set obtained from the first-level tree. The specific steps are: traverse the candidate record set, and for each record, recursively calculate the Boolean value starting from the leaf node according to the structure of the second-level logic tree. The leaf node calls the corresponding evaluation function (e.g., "name contains 'engineering'"), and the return value is passed to the parent node for AND / OR / NOT operations, ultimately determining whether the record conforms to the second-level tree. Only records that conform are output as the final result.

[0197] Step S160 transforms the logical relationship of the condition phrases into independent first-level and second-level logical trees, thereby achieving hierarchical execution of indexing acceleration and precise filtering. This avoids premature row-by-row scanning on difficult-to-index second-level conditions while ensuring the correctness of the condition combination.

[0198] S170. Map the attribute names in the directory structure description phrase to the metadata field names through field semantic mapping, and generate a path template placeholder sequence in the order described by the directory structure description phrase.

[0199] Step S170 transforms the user's description of the data storage hierarchy in natural language (e.g., "documents stored by department and then by year") into an abstract sequence of path template placeholders. Simultaneously, it uses field semantic mapping to bind the attribute names in the description (such as "department" and "year") to the actual metadata fields in the database. This is particularly important considering that many retrieval scenarios require not only filtering conditions (rule sets) but also a clear understanding of the data's physical storage location pattern. Especially in environments such as distributed file systems, partitioned tables, and object storage, the path structure itself is an efficient indexing method that can significantly reduce the scan scope. Without this step, only a full table scan or reliance on ordinary indexes would be possible, failing to leverage the pruning capabilities of the path hierarchy.

[0200] In specific implementation, step S170 first performs semantic parsing on the "directory structure description phrase" input by the user. However, unlike the field mapping of conditional phrases, which is for value comparison in subsequent evaluation functions, the mapping here is to determine the metadata field names corresponding to each level in the path template. For example, if the user says "documents are organized by department and year", the attribute name sequence ["department", "year" is extracted. Then, these are mapped to metadata fields respectively: assuming the field names in the database are dept_name and publish_year, the mapping result is [dept_name, publish_year]. Since these field names will be used as placeholders in subsequent steps, the mapping process must ensure a one-to-one correspondence and that the fields exist. At the same time, the hierarchical order of the original description is preserved, such as "department above, year below", and cannot be arbitrarily changed, because the hierarchical order of the path template directly corresponds to the nesting level of files or partition directories. If it is disordered, the generated path will not match the actual storage structure.

[0201] Next, a sequence of path template placeholders is generated in this order. Placeholders are special markers, typically enclosed in curly braces around field names, such as {dept_name} and {publish_year}. They are embedded in a string template, the format of which is inferred from a preset or user description. For example, if the data is stored in a path like / data / {dept_name} / {publish_year} / , then step S170 generates such a template string, where the specific value of each placeholder is replaced with the actual field value (from the rule set or a full scan) during subsequent execution. This template itself does not contain specific paths, only describing the structure. Its function is equivalent to a "path index skeleton," allowing step S200 to calculate which specific directories need to be scanned based on conditions in the rule set (such as publish_year=2020), without traversing all directories. In the actual algorithm, if a condition in the first-level logic tree happens to correspond to a field in the path template (such as the equality condition for dept_name), the path range can be directly pruned using the constraint of that field, equivalent to performing partition pruning at the path level.

[0202] In step S200, the execution engine receives two inputs: the first-level and second-level logical trees generated in step S160 (used to filter records), and the path template and its field mapping relationships generated in step S170. Step S200 first parses the path template, combining it with the conditions for path fields in the first-level logical tree (e.g., dept_name='Engineering Department'), constructing an index scan range for each possible path prefix (e.g., scanning only all subdirectories under / data / Engineering Department / ), and then loading candidate records from these paths. Then, it performs a second-level logical tree evaluation on the candidate records. The existence of the path template allows a large number of partitions or directories that do not meet the range to be skipped, significantly improving retrieval efficiency.

[0203] Furthermore, the intelligent tag inverted index is constructed in real time based on the evaluation results of data blocks according to search intent.

[0204] The intelligent tag inverted index is an inverted index structure built in real time based on a specific set of query rules. Its core is to use each atomic condition as the key and the true or false value of the evaluation result as the secondary key, recording the identifiers of all data blocks that satisfy or do not satisfy that condition. Its function is to transform the computation process, which originally required calling the evaluation function and combining logic line by line, into set-based intersection, union, and complement operations, thereby significantly accelerating the filtering of multiple condition combinations under the logical expression tree structure. When the query contains a large number of secondary rules (where precise matching and inclusion judgments cannot be used with conventional indexes), the traditional approach is to sequentially execute all secondary evaluation functions for each candidate data block, resulting in a time complexity of O(log n). ( For the number of data blocks, (This refers to the number of atomic conditions). However, using an inverted index, it is only necessary to traverse all candidate data blocks and calculate all atomic conditions once to construct a... Given a set of true / false conditional pairs, the system only needs to perform intersection, union, and complement operations on the sets. These operations can typically be performed in constant or near-linear time in set data structures (such as bitmaps or hash sets), significantly reducing the cost of repeatedly executing the evaluation function.

[0205] Figure 4 The following steps are shown in one embodiment for constructing a smart tag inverted index:

[0206] S211, Collect all atomic conditions in the rule set;

[0207] S212. Create an empty dictionary;

[0208] S213. For each atomic condition, create True and False keys in an empty dictionary. The initial value for each key is an empty set used to store the data block ID.

[0209] S214. Obtain the complete set of data blocks;

[0210] S215. Execute the evaluation functions of all atomic conditions on the contents of the data blocks in the entire set of data blocks in turn to obtain Boolean values;

[0211] If the evaluation result is True, then add the data block ID to the corresponding True key set;

[0212] If the evaluation result is False, then add the data block ID to the corresponding False key set;

[0213] S216. After the traversal is completed, the intelligent tag inverted index is constructed.

[0214] Create an empty dictionary (denoted as `inverted`). For each atomic condition, establish two keys in the dictionary: one for "true" and one for "false". The initial value of each key is an empty set used to store data block identifiers. Next, obtain the complete set of data blocks. This complete set can be the candidate data block set pruned from the first-level logic tree using the path template in step S200 (e.g., the path template limits certain directories or partitions), or it can be all data blocks. Then, for each data block in the complete set, execute the evaluation function for all atomic conditions to obtain the Boolean result for each condition. If the result is true, add the identifier of the current data block (such as the data block number or path) to the "true" set corresponding to that condition; if the result is false, add it to the "false" set. After traversal, the smart tag inverted index is completed. At this point, each atomic condition in the dictionary is associated with two sets.

[0215] The new inverted index model involves two steps: First, constructing the inverted index. This can be done using only the candidate data blocks selected from the first-level tree as the complete set, or it can include all data blocks defined by the path template. The construction process itself executes all atomic conditions (including the evaluation function of the first-level conditions) on each data block in the complete set. However, the first-level conditions are usually optimized by indexes; here, the inverted index can be constructed only for the second-level conditions, or all conditions can be constructed. Second, set operations are performed using a logical expression tree (which can be a complete second-level tree or a combination of first-level and second-level trees): the condition corresponding to each leaf node in the logical tree is replaced with a set of "true" or "false" values ​​for that condition (the choice is based on the logical sign). Then, AND is converted to intersection, OR to union, and NOT to complement, recursively calculating to obtain the final set of data block identifiers that satisfy the entire expression tree. This step completely avoids line-by-line evaluation, relying solely on set operations. Finally, only the data blocks in this final set are read or returned. Thus, the inverted index acts as a one-time cache for the evaluation results, reducing computational complexity from... Reduce to The construction overhead plus It performs set operations, and the construction process itself is parallelizable; more importantly, for the same condition referenced multiple times in the same search intent (such as multiple clauses sharing the same condition), the inverted index only needs to be calculated once.

[0216] The path template limits the scan range of data blocks before execution, so the entire set built by the inverted index can be precisely limited to these ranges, avoiding unnecessary full scans and further improving the efficiency of real-time construction. At the same time, the "data block identifier" in the inverted index is usually the path string or partition key value, which is naturally compatible with the placeholder replacement mechanism of the path template.

[0217] Figure 5 The following steps are illustrated in one embodiment for performing set operations according to the logical relationships defined by the rule set:

[0218] S217. Retrieve the set required for each leaf node of the first-level logic tree from the smart tag inverted index;

[0219] The set operations are performed on the selected set from bottom to top according to the operators in the first-level logic tree to obtain the first-level result set;

[0220] S218. Retrieve the corresponding set from the smart tag inverted index based on the leaf nodes of the second-level logic tree;

[0221] Perform set operations from bottom to top according to the structure of the two-level logic tree to obtain a set of intermediate results for the second level;

[0222] S219. Perform an intersection operation on the first-level result set and the second-level intermediate result set, and use the resulting final set as the data block hash set of the rule set.

[0223] First, step S217 operates on the first-level logic tree. Each leaf node in the first-level logic tree corresponds to an indexable first-level atomic condition. These conditions already have their own corresponding "true" sets (i.e., the set of data block identifiers on which the condition evaluates to true) and "false" sets (the set of data block identifiers that evaluate to false) in the smart tag inverted index. Based on the structure of the first-level logic tree, the required set for each leaf node is extracted from the inverted index: if the leaf node appears as a positive condition in the logic tree (i.e., without the NOT operator), its "true" set is taken; if it is negated (i.e., with the NOT operator), its "false" set is taken (because NOT is equivalent to negation). Next, according to the logical semantics of the operators in the first-level logic tree, set operations are performed on the extracted sets sequentially from bottom to top. When encountering the "AND" operator, the intersection of the sets of two child nodes is calculated; when encountering the "OR" operator, the union is calculated; and when encountering the "NOT" operator, the complete complement of the child node sets is calculated (but the complete complement is usually limited to the candidate data block set scanned by the first-level logic tree). The bottom-up execution order ensures that the results of sub-expressions can be correctly used by parent nodes, avoiding duplicate calculations, and is consistent with the associative law of logical operations. After the calculation is complete, a first-level result set is obtained, which contains the identifiers of all data blocks that satisfy the first-level logical tree Boolean expressions. This set means that these data blocks are determined to meet the filtering criteria under all combinations of first-level conditions, and therefore they can be directly used as the results of index pre-filtering.

[0224] Following step S218, a similar operation is performed on the second-level logic tree. Each leaf node of the second-level logic tree corresponds to a second-level atomic condition that needs to be evaluated row by row, and also has "true" and "false" sets in the smart tag inverted index. Here, set operations are also performed from bottom to top, calculating the second-level intermediate result set based on the operator structure (AND, OR, NOT) of the second-level logic tree. The meaning of this set is: it represents those data blocks that satisfy the second-level logic tree only from the perspective of the combination of second-level conditions, but have not yet considered the first-level conditions. Note that the calculation of the second-level intermediate result set is performed within the same global set as the first-level logic tree, therefore the complement operation is also based on the same global set.

[0225] The final step, S219, performs an intersection operation on the first-level result set and the second-level intermediate result set to obtain the final set. Only the intersection is performed because the first-level and second-level conditions in the original rule set are connected by an implicit "AND" relationship. The logical expression of the entire rule set is equivalent to "first-level logic tree AND second-level logic tree". This was guaranteed during the separation of the two trees in step S160; after replacing the leaf nodes in the first-level tree with True, the remaining logic is the second-level tree, and vice versa. Furthermore, there is no "OR" relationship between the first and second levels in the original query (if there were, it would be handled as a cross-tree operation during tree splitting, but it is usually stipulated that both the first and second levels must be satisfied simultaneously). Therefore, the data block that ultimately satisfies the complete rules must be in both the first-level result set and the second-level intermediate result set; taking the intersection is the only correct operation. The resulting set is called a "data block hash set" because it uses a hash set (e.g., a set implemented based on a hash table) as its storage structure. This provides constant-time lookup performance in subsequent data retrieval or association operations, and it is also easy to combine with the results of other rule sets through union, intersection, and other further operations. Each element in the hash set is a data block identifier, typically a hash value or path code, facilitating rapid location of the data block. This set serves as a one-time index output for the rule set and can be directly used in subsequent data reading or return steps, significantly reducing the number of data blocks that need to be actually read. The bottom-up set operation model is the core of this execution flow. It fully utilizes the pre-computed set in the inverted index, transforming logic tree evaluation into efficient set union and intersection operations, while maintaining accurate mapping of complex nested logic, ultimately obtaining an accurate set of data block candidates with minimal overhead.

[0226] Figure 6 The steps for reading a list of smart tag values ​​associated with a tag, as shown in one embodiment, include:

[0227] S221. Using the current data block ID as the key, initiate a point query to the label mapping table;

[0228] If the query finds a match, it returns a list containing all the smart tag values ​​for that data block.

[0229] If the query returns no match, an empty list is returned.

[0230] In step S221, each data block identifier in the set is retrieved sequentially and used as the lookup key to initiate a point query to the tag mapping table. The current data block identifier is used as the key because the tag mapping table is designed with data block identifiers as indexes. Each identifier is unique and immutable in the system, accurately corresponding to all tag field values ​​of its respective data block. A point query refers to retrieving the corresponding value directly by key within constant time (usually using an in-memory hash table or a persistent key-value store index), without traversal or range scanning, thus achieving extremely high efficiency and enabling batch processing of hundreds or even millions of identifiers. The specific method of initiating a point query depends on the underlying storage engine. If the tag mapping table is stored in local memory, it corresponds to a `map.get(key)` operation; if stored in a remote cache (such as Redis), a GET command for a network request is executed; if it is a persistent database, a single-row query is performed using the primary key index. Regardless of the implementation, extremely low latency for a single query is ensured.

[0231] The tag mapping table itself is built during the data block ingestion phase. After each data block is parsed, the system extracts the actual values ​​of all its tag fields (e.g., Department="Engineering Department", Year="2020"), organizes these values ​​into a string list, and then stores the list in the mapping table using the unique identifier of the data block as the key. Simultaneously, the intelligent tag inverted index is built in the opposite direction (tag value → set of data block identifiers). Together, they form a bidirectional index structure. The inverted index is used to quickly filter identifiers that meet the conditions, while the mapping table is used to restore the identifiers to their original tag content. Therefore, the tag mapping table is not generated temporarily at runtime, but is pre-built and kept synchronously updated along with the inverted index.

[0232] When a query returns a successful result, it indicates that the data block was correctly indexed during storage and has a defined list of tag values. The system directly returns this list for subsequent processing. If a match is missed, it means that the data block may not have been registered in the mapping table for some reason (such as data corruption, missing tag fields, or incomplete indexing). In this case, an empty list is returned. Therefore, regardless of whether a match is found or not, the caller receives a list object (either non-empty or empty), without needing to additionally check its existence. An empty list can still participate in merging and deduplication (an empty list does not contribute any elements), filtering (conditions are never met), or packaging and returning (the tag list is empty) in subsequent steps, ensuring the robustness of the process and the simplicity of the code. More importantly, a match does not necessarily represent an error. Some data blocks may not naturally have any smart tags. In this case, an empty list precisely reflects their actual attributes, avoiding the risk of forcibly assigning incorrect values. This mechanism allows the system to operate smoothly even in the face of anomalies or edge cases.

[0233] S222. For each data block ID and its corresponding tag list, the processing method is determined based on the next business requirement, including:

[0234] The next business requirement is to construct the display content of virtual folders. This involves merging the tag lists of multiple data blocks into a global list and removing duplicates. The significance is to provide users with a file browsing view organized by tag values, replacing the traditional directory tree structure. In this view, each tag value (such as "Engineering Department," "2020," or "Report") becomes a virtual folder. Clicking on a folder allows the user to further display all data blocks with that tag. During implementation, the system needs to aggregate the tag lists of all data blocks, generating a global, unique set of tag values. Specifically, it iterates through each data block in the current dataset, reading its tag list one by one, and concatenating each element in the list into a deduplication container (such as a hash set). Since containers naturally eliminate duplicates, the final result is all the unique tag values ​​that have appeared. Merging and deduplication is necessary because multiple data blocks may share the same tag values ​​(for example, multiple data blocks may all belong to "Engineering Department"). Without deduplication, duplicates would appear in the virtual folders, causing visual confusion and logical inconsistencies. The deduplicated set can then be directly used to construct a directory hierarchy for front-end rendering or further tag-based grouping and querying.

[0235] The next business requirement is further filtering. Therefore, conditional checks are performed on each tag list to filter out data block IDs that meet secondary conditions. This allows users to apply a second, more refined filter based on tag values, narrowing down the scope beyond the initial rule set. For example, the initial rule might require "Department = Engineering Department and Year = 2020," while secondary filtering might require "Type = Report." In this case, only data blocks whose tag lists contain "Report" should be retained within the subset that meets the initial conditions. During implementation, conditional checks are performed on the tag list of each data block. The condition can be a Boolean expression (e.g., tag list contains "Report"), a regular expression match, or a value range (e.g., year greater than 2019). The check method typically uses a linear scan of the list or leverages a pre-built tag value dictionary for acceleration. If the check passes, the data block identifier is added to a new subset; otherwise, it is discarded. This step allows users to flexibly adjust the filtering granularity without re-executing the entire rule matching process (the latter may involve multi-condition intersection, union, and complement operations on inverted indexes, which are costly). By directly manipulating the tag list, the system can complete secondary filtering with minimal delay, improving the user experience.

[0236] The next business requirement is to return the result to the upper layer request. Therefore, each data block ID and its tag list are combined into a key-value pair, stored in a result set, and then output. The significance is that it packages the data block identifier and its associated tag information into a structured result set for transmission to external callers (such as front-end interfaces, data pipelines, or third-party services). The upper layer request needs to obtain both "which data blocks meet the conditions" and "what tags each of these data blocks has" for direct display or further processing. Specifically, it iterates through each data block identifier and its tag list, combining them into a key-value pair structure (e.g., {"identifier": "abc123", "tag list": ["engineering department", "2020", "report"]}), then appends them sequentially to an array or set, and finally outputs the entire result. This step does not perform any transformation or filtering, maintaining the integrity of the original information and ensuring the upper layer has all the necessary data sources. The advantage of this approach is that the lower-level module only needs to provide a one-time query result; the upper layer does not need to query the tag mapping table separately, reducing communication rounds and coupling.

[0237] Figure 7 The following steps are illustrated in one embodiment where each data block is assigned a virtual path string, including:

[0238] S231. Read the path template corresponding to the current rule set and decompose it into an ordered list of placeholders;

[0239] S232. For the smart label value list of the current data block, traverse each label and determine its dimension through dimension attribution mapping;

[0240] S233. According to the order of the placeholders in the placeholder list, retrieve the values ​​of the corresponding dimensions from the dimension attribution mapping in turn, replace the placeholders in the path template, and obtain the virtual path string;

[0241] S234. Bind the generated virtual path string to the data block ID.

[0242] The purpose of the above steps is to calculate a virtual path string for each data block, enabling the data blocks to be organized hierarchically by dimension within a virtual folder. Step S232 is the key step in the entire process. In this scheme, a dimension is an abstract classification of a smart label field. Each smart label belongs to a specific dimension; for example, "department," "year," and "type" are different dimensions. Dimensions define the classification axis of the data block within the organizational hierarchy, and the virtual path string is a hierarchical path constructed based on these dimensions. The dimension itself is not a label value, but rather the category to which the label value belongs.

[0243] Step S232 aims to transform the unordered list of smart tag values ​​in the current data block into a dimension-to-value mapping. Because the smart tag value list only contains specific values ​​(e.g., "Engineering Department", "2020", "Report"), it doesn't specify which tag field each value belongs to. Since the placeholders in the path template are named according to dimension names (e.g., "{Department}", "{Year}", "{Type}"), it's essential to know the dimension corresponding to each tag value to correctly fill it into the corresponding placeholder position in the template. Dimension attribution mapping is the tool for achieving this reverse lookup: it's a predefined mapping table where the key is the specific value of the smart tag, and the value is the dimension to which that value belongs. For example, "Engineering Department" → "Department", "2020" → "Year", "Report" → "Type". This mapping table is built synchronously when smart tags are added to the database, or statically generated based on the definition of the tag fields (which dimension each field belongs to).

[0244] During implementation, the list of label values ​​for the current data block is traversed. For each label value, the dimension mapping is queried using that value as the key to obtain the corresponding dimension name. If a unique dimension is found for all label values, a temporary dimension-value mapping is formed by combining these dimensions with the label values ​​and stored in the current data block context. Since a data block can have multiple labels, but each dimension is usually only allowed one value (otherwise the path would be chaotic), the actual implementation needs to ensure that each dimension has a unique value within the data block. If a dimension corresponds to multiple label values, it needs to be handled according to predefined rules (such as taking the first value or reporting an error). After this step is completed, the system obtains the dimension-value mapping for the data block, for example, {"Department": "Engineering Department", "Year": "2020", "Type": "Report"}.

[0245] In step S233, according to the order of the placeholder list (e.g., "Department", "Year", "Type"), the values ​​of the corresponding dimensions are sequentially retrieved from the aforementioned dimension-value mapping and used to replace the placeholders in the path template, thus obtaining the virtual path string (e.g., " / Engineering Department / 2020 / Report"). This is feasible because the path template itself is an ordered definition of the dimension hierarchy, and the order of the placeholders determines the nesting level of the virtual directory. Each placeholder represents a dimension level, and the string generated after replacement naturally reflects the specific position of the data block when organized according to these dimensions. If the dimension-value mapping lacks a dimension corresponding to a placeholder, it may result in the corresponding level in the path being empty, requiring processing according to business rules (e.g., using default values ​​or discarding).

[0246] Optionally, replacing placeholders in the path template includes:

[0247] If the corresponding dimension has a value in the dimension attribution mapping, then replace it with that value itself;

[0248] If the corresponding dimension is missing in the dimension attribution mapping, a default value is used. The default value acts as a fallback; when a dimension is not present in a data block, the default value is used to fill that level. The specific meaning of the default value depends on the system design or business rules, and generally falls into two categories:

[0249] Firstly, there are default values ​​with explicit business semantics: such as strings with actual meaning like "global," "undefined," and "none." These values ​​will appear as an additional static directory node in the virtual folder, grouping all data blocks lacking that dimension label together for easy user identification and overview. For example, all data blocks without the "year" label will appear under the path " / Engineering Department / Undefined / Report." This helps reveal gaps in data coverage and may also provide clues for subsequent data governance.

[0250] Secondly, structured reserved default values: such as empty strings "" or special placeholders "". While using empty strings maintains the same number of path levels, it results in two consecutive forward slashes in the path (e.g., " / Engineering Department / / Report"), which is illegal or ambiguous in most file systems. Therefore, it's more common to use a single underscore "" or a period "." as a placeholder to indicate that the level exists but the content is missing. This makes the path appear as " / Engineering Department / _ / Report", preserving the hierarchical structure while still allowing the parser to correctly identify it as a complete path segment.

[0251] Choosing default values ​​requires balancing business visualization with system compatibility. If the business wants users to immediately understand which data blocks are missing labels for specific dimensions, then descriptive default values ​​are better. If strict consistency in path format is required (e.g., for subsequent string matching or persistent storage), then using a single, parsable reserved character is more appropriate. Essentially, default values ​​are a fault-tolerance mechanism for incomplete data, ensuring that the generation of virtual paths is not affected by individual missing values. This allows all data blocks to be indexed and retrieved within the same path system, preventing isolated data blocks that cannot be categorized due to missing fields. Simultaneously, it unifies the path format of all data blocks, allowing path-based query, sorting, and traversal logic to be executed seamlessly without the need to write special conditions for missing dimensions.

[0252] It's important to note that the purpose of the virtual path string is to assign a file system-like hierarchical address to each data block, allowing users to browse data blocks by drilling down layer by layer without needing to write complex filtering rules. This transforms the data block retrieval method from rule-driven to path navigation. Furthermore, the path string itself is readable and deterministic, facilitating the presentation of a directory tree in the front-end interface and enabling operations such as string range matching and depth-first traversal.

[0253] Finally, step S234 binds the generated virtual path string to the data block identifier. The same virtual path may correspond to multiple data blocks (e.g., multiple files under the same department, year, or type), and the path itself is not unique. After binding the path to the identifier, the system can quickly find all data block identifiers under that path to display content during navigation; on the other hand, when a specific data block needs to be operated on, its path can be retrieved through the identifier for location or movement. The binding operation typically uses a hash table or inverted index storage (path → identifier list), ensuring efficient mutual lookup between the two. In this way, the virtual folder system can organize data blocks at the lower level using path strings, while the upper level performs specific data operations through identifiers, achieving separation of organization and access.

[0254] Figure 8 The steps for dynamically rendering a virtual path string into a browsable directory tree are shown, including:

[0255] S241. Collect the virtual path strings corresponding to all data blocks;

[0256] S242. For each virtual path string, split it into a list of fragments by a delimiter, and insert all the fragment lists as a trie (also known as a prefix tree). Each path string is split into an ordered list of fragments by a delimiter (e.g., " / Engineering Department / 2020 / Report"), for example, " / Engineering Department / 2020 / Report" is split into ["Engineering Department", "2020", "Report"]. Then, starting from the first fragment in this list, each fragment is inserted into the trie as a node key. All path strings share the same trie root node. When multiple paths have the same prefix (e.g., " / Engineering Department / 2020"), the trie can merge these common prefixes to avoid repeatedly storing the same intermediate nodes. The trie is naturally suitable for representing sets of paths with common prefixes. It compresses storage through node sharing while preserving the complete hierarchical relationship of each path. After the insertion operation, the trie itself is a multi-way tree, where each node (except the root node) corresponds to a fragment (i.e., a directory name), and each node can have multiple child nodes representing different next-level directories. For example, the root node has child nodes such as "Engineering Department" and "Marketing Department," and each department node has child nodes for the year "2020," "2021," etc., and so on. In this tree structure, each node corresponds to a subfolder in the virtual folder, and the root node corresponds to the root directory of the virtual system.

[0257] S243. Starting from the root node, recursively traverse the tree, with each node becoming a folder node, ultimately resulting in a multi-way tree. This recursion is essentially a depth-first traversal of the trie constructed in the previous step. Specifically, starting from the root node, visit all its child nodes, and for each child node, recursively visit its child nodes. During the traversal, a folder node data structure is created for each node, containing: the name of the current node (i.e., the corresponding fragment value), a list (or array) of pointers to its child folder nodes, and other metadata. After the recursive traversal is complete, the trie is completely transformed into a pure tree structure composed of folder nodes, i.e., a multi-way tree (each parent node can have any number of child nodes). This step is necessary because the trie is essentially for string retrieval, and its nodes may contain internal states (such as counts, end markers), while we need a pure tree structure that conforms to folder semantics for subsequent rendering. The recursive process simply maps the original hierarchy to folder nodes without adding or removing any content. This multi-way tree is the data model of the virtual folder system at the logical layer. It clearly depicts the directory hierarchy of all data blocks: the root of the tree represents a virtual root directory, each internal node represents a virtual folder, and each path from the root to a node (which could be an intermediate or leaf node) corresponds to a common prefix for multiple data blocks. For example, all data blocks under the node "Engineering Department" → "2020" → "Report" are the set of data blocks that have the complete path " / Engineering Department / 2020 / Report". Therefore, this multi-way tree provides a complete location index and navigation skeleton for subsequent interactions and queries.

[0258] It's important to note that virtual folders are not actual file systems; they are entirely built upon this multi-branch tree. Each expandable folder a user sees is essentially a node in this tree; the directory structure the user browses is the layer-by-layer expansion of this tree. The core function of the virtual folder system—drilling down through data blocks by dimension—is achieved by manipulating this tree. When a user clicks on a folder node, the system uses the path prefix corresponding to that node (i.e., the concatenation of all segments from the root to that node) to query all data block IDs with matching prefixes, and then returns them to the front end for display.

[0259] S244. Render the tree nodes as interactive components. The specific rendering method depends on the front-end technology stack, but the principle is universal: use the root node of the multi-branch tree as the top-level component, and recursively render each node as an expandable folder icon and name. A common implementation is to use a front-end framework (such as React or Vue) to write a tree component that receives the tree data (a list of nodes) and uses a recursive template to generate the DOM. Each node will be bound to the following interactive behaviors:

[0260] Click (or double-click) the node itself to toggle the expanded / collapsed state of the current folder (i.e., show or hide its child nodes).

[0261] When a node is clicked, an event is triggered, which sends the complete path of the current node (a concatenation of fragments from the root to the node) to the backend. The backend retrieves all data block IDs based on the path prefix and returns a list of data blocks. The frontend then displays these data blocks (such as a file list table or card) in a panel.

[0262] It may also support advanced interactions such as right-click menus and drag-and-drop sorting.

[0263] One possible implementation involves recursively injecting the tree structure into the DOM. In common web front-end implementations, step S244 would use a component-based framework (such as React, Vue, or native JavaScript) to write a recursive tree component. This component receives a list of nodes (i.e., an array of root nodes of the multi-way tree) and performs a depth-first traversal. For each node, the rendering template outputs an HTML structure:

[0264] A container div or li element that contains a folder icon (or an extended icon);

[0265] Node name text (i.e., the dimension value corresponding to this segment, such as "Engineering Department");

[0266] A clickable expand / collapse button (usually a small arrow or plus / minus icon);

[0267] A container for child nodes (hidden by default) used to recursively render the list of child nodes.

[0268] The key to recursive rendering lies in controlling the display of child node containers through the state variable `isExpanded` when the current node is expanded. When `isExpanded` is true, the component iterates through the node's `children` array, calling itself again for each child node (i.e., recursively calling), until all leaf nodes have been rendered. In this way, all nodes in the entire multi-branch tree ultimately exist on the page as nested DOM elements, but only the expanded path is visible. The style and indentation level of each node are controlled by CSS (e.g., increasing `padding-left` layer by layer), thus presenting a clear directory hierarchy.

[0269] Interactive components are UI parts that are bound to event listeners and can respond to user actions, triggering state changes or data requests. Specifically, for a tree component:

[0270] Click on the node name or folder icon: Trigger a selection event and send the full path of the current node (the concatenation of all segments from the root to this node, such as " / Engineering / 2020 / Report") as a parameter to the backend. At the same time, the component itself will add a "selected" style (such as a highlighted background).

[0271] Click on the expand / collapse button: Toggle the local isExpanded state of the node and trigger a reactive update in Vue or React to re-render the child node container of this node (show or hide).

[0272] Mouse hover: Display a tooltip showing metadata such as the number of data blocks corresponding to this node.

[0273] Right-click menu: May provide operations such as "Copy Path", "View Details", etc.

[0274] These interaction behaviors are essentially a bridge between front-end event handling functions and back-end APIs. The state of the component (expanded / collapsed, selected) is maintained using the local state management of the framework (such as React's useState or Vue's data).

[0275] After rendering and displaying in the browser, the entire tree component is the virtual folder hierarchy seen by the user's eyes. It has no corresponding support from the real file system, but its appearance and behavior are exactly the same as the folder tree sidebar in Windows Explorer. Each node is a virtual folder, and its name is determined by the path segment. Users can browse the subdirectories under this virtual folder by expanding and collapsing nodes. For example, when the user expands the "Engineering" node, its child nodes "2020", "2021", etc. appear, just like a real folder containing subfolders.

[0276] When the user clicks on any node (folder), the event handling function bound to this node is executed. It first stops the event bubbling to avoid triggering the click of the parent node, and then makes a front-end AJAX call to the back-end interface, such as GET / api / vfolder / files?path= / Engineering / 2020. After receiving the request, the back-end looks up all data block IDs with " / Engineering / 2020" as the prefix from the virtual path index (i.e., the mapping of the previously stored virtual path string and data block ID), and returns the metadata (file name, size, type, upload time, etc.) corresponding to these data blocks. The front-end renders the returned data list into another panel (such as a file list table). This panel is usually located on the right or below the tree component, forming a master-slave layout with the tree component.

[0277] When the file list is rendered as clickable rows or cards, each file item is also bound to a click event. Upon clicking, the frontend calls the backend file download or preview API (e.g., GET / api / vfolder / file / :id / download) based on the file's ID or storage path. The backend responds with a file stream, and the browser decides whether to open it directly (e.g., PDFs and images can be previewed in a new tab) or trigger a download based on the file type. This operation is independent of the tree component's interaction and is a second step separate from folder browsing.

[0278] Specifically, the operation of clicking a node to view its contents relies on the onClick handler function bound to each node in the tree component. This function must know the complete path of the current node, which is extracted from the tree node data structure. If step S244 does not render a clickable node, there is no entry point to trigger the query.

[0279] The tree component's expand / collapse mechanism allows users to drill down level by level, gradually narrowing the scope of their intent. This mechanism is the core of the virtual folder browsing logic and is driven by the local state (isExpanded) created during rendering in step S244.

[0280] Although the final file opening operation does not directly depend on the tree component, the retrieval of the file list (i.e., viewing the folder contents) must be triggered by clicking on a tree node. Therefore, the tree component is the remote control for user interaction with backend data.

[0281] In summary, step S244 visualizes the abstract tree data as UI components with visual hierarchy and interactive capabilities. All subsequent user operations (browsing folders, viewing content, opening files) are built upon the events and states provided by these components. Without this step, the virtual folder is merely a logical concept, unperceived and unmanageable by the user.

[0282] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. An accounting file archiving path driving method, characterized by, Includes the following steps: Receive the user's search intent expressed in natural language, and extract the rule set and path template through semantic parsing; Creating a virtual folder includes: For each atomic condition in the rule set, a query is performed in the smart tag inverted index. The query results of all atomic conditions are then subjected to set operations according to the logical relationship defined in the rule set to obtain the data block hash set of the rule set. For each hash value in the hash set, read the list of its associated smart tag values; Each data block is assigned a virtual path string; Dynamically render virtual path strings into a browsable directory tree.

2. The accounting file archiving path driving method of claim 1, wherein, The steps for extracting the rule set and path template through semantic parsing include: The system performs word segmentation and phrase boundary recognition on the natural language input by the user, dividing it into several independent conditional phrases and identifying possible directory structure description phrases. Each conditional phrase is input into a pre-trained language model to obtain a semantic vector; Based on the semantic vector of the conditional phrase and its position in the sentence, dependency relations, and surrounding conjunctions, it is determined whether each conditional phrase belongs to a first-level rule or a second-level rule; the first-level rule includes scope, time period, and major category limitation; the second-level rule includes attributes and operations. For each condition phrase, the corresponding metadata field name is determined through field semantic mapping; Each conditional phrase is compiled into an executable evaluation function; Based on the connectors and negations between conditional phrases, multiple evaluation functions at the same level are combined into a logical expression tree. The conditional phrases of the first-level rules form a first-level logical tree, and the conditional phrases of the second-level rules form a second-level logical tree. The attribute names in the directory structure description phrase are mapped to metadata field names through field semantic mapping, and a sequence of path template placeholders is generated in the order described by the directory structure description phrase.

3. The accounting file archiving path driving method according to claim 1 or 2, characterized by, The intelligent tag inverted index is constructed in real time based on the evaluation results of data blocks according to search intent.

4. The accounting record archiving path-driven method according to claim 2, characterized in that, The steps for constructing the intelligent tag inverted index include: Collect all atomic conditions in the rule set; Create an empty dictionary; For each atomic condition, create True and False keys in an empty dictionary. The initial value for each key is an empty set used to store the data block ID. Get the complete set of data blocks; The evaluation functions for all atomic conditions are applied sequentially to the contents of each data block in the entire dataset, yielding Boolean values. If the evaluation result is True, then add the data block ID to the corresponding True key set; If the evaluation result is False, then add the data block ID to the corresponding False key set; After the traversal is complete, the smart tag inverted index is built.

5. The accounting record archiving path-driven method according to claim 4, characterized in that, The steps for performing set operations according to the logical relationships defined in the rule set include: Retrieve the set required for each leaf node of the first-level logic tree from the smart tag inverted index; The set operations are performed on the selected set from bottom to top according to the operators in the first-level logic tree to obtain the first-level result set; Retrieve the corresponding set from the smart tag inverted index based on the leaf nodes of the second-level logic tree; Perform set operations from bottom to top according to the structure of the two-level logic tree to obtain a set of intermediate results for the second level; Perform an intersection operation on the first-level result set and the second-level intermediate result set, and the resulting final set is used as the data block hash set of this rule set.

6. The accounting record archiving path-driven method according to claim 1, characterized in that, The step of reading the list of smart tag values ​​associated with it includes: Use the current data block ID as the key to initiate a point query to the label mapping table; If the query finds a match, it returns a list containing all the smart tag values ​​for that data block. If the query returns no match, an empty list is returned.

7. The accounting record archiving path-driven method according to claim 6, characterized in that, The step of reading the list of smart tag values ​​associated with it includes: For each data block ID and its corresponding tag list, the processing method is determined based on the next business requirement, including: The next business requirement is to construct the display content of the virtual folder, which means merging the tag lists of multiple data blocks into a global list and removing duplicates; The next business requirement is to further filter the data, so conditional judgments are performed on each tag list to filter out the data block IDs that meet the secondary conditions. The next business requirement is to return the data to the upper layer request, so the ID of each data block and the list of tags are combined into a key-value pair, stored in the result set, and then output.

8. The accounting record archiving path-driven method according to claim 1, characterized in that, The step of assigning a virtual path string to each data block includes: Read the path template corresponding to the current rule set and break it down into an ordered list of placeholders; For the current data block's list of smart label values, iterate through each label and determine its corresponding dimension through dimension attribution mapping; Based on the order of the placeholders in the placeholder list, the values ​​of the corresponding dimensions are retrieved from the dimension attribution mapping in turn, and the placeholders in the path template are replaced to obtain the virtual path string; Bind the generated virtual path string to the data block ID.

9. The accounting record archiving path-driven method according to claim 8, characterized in that, The placeholders in the replacement path template include: If the corresponding dimension has a value in the dimension attribution mapping, then replace it with that value itself; If the corresponding dimension is missing in the dimension attribution mapping, the default value is used.

10. The accounting record archiving path-driven method according to claim 1, characterized in that, The step of dynamically rendering the virtual path string into a browsable directory tree includes: Collect the virtual path strings corresponding to all data blocks; For each virtual path string, split it into a list of fragments by the delimiter, and insert all the fragment lists as a trie; Starting from the root node, the process is recursively repeated, with each node becoming a folder node, eventually resulting in a multi-branch tree; Render tree nodes as interactive components.

Images