Accounting data intelligent retrieval and analysis method and system combined with AI

Abstract

The present application relates to the technical field of accounting data processing, and more particularly to an accounting data intelligent retrieval and analysis method and system combined with AI. A set of accounting vouchers is obtained and combined coding is performed to generate a voucher embedding vector, and a subject authority semantic index library is constructed according to a multi-level authority hierarchy tree; a query embedding vector is generated by receiving an accounting retrieval query, and a subject authorization identifier set is determined, the set is used as an access voucher to locate an authorized subject partition, and then cosine similarity retrieval is performed to obtain a candidate result set, and finally comprehensive sorting is performed for output; the semantic retrieval mechanism of authority isolation improves the accuracy and security of accounting data retrieval.

Description

Technical Field

[0001] This invention relates to the field of accounting data processing technology, and in particular to a method and system for intelligent retrieval and analysis of accounting data that combines AI. Background Technology

[0002] Current accounting data retrieval technologies primarily rely on Structured Query Language (SQL) and keyword matching. When storing vouchers in accounting information systems, enterprises typically treat fields such as summary, account code, debit / credit direction, and transaction amount as independent attributes. During retrieval, user-input conditions are compared precisely or fuzzily against these fields. Access control is implemented by binding user role tables to account code ranges; that is, the system predefines a list of account hierarchy nodes that each role can access. During queries, account codes are first filtered by role before the retrieval operation is performed. This model can maintain basic functionality in small- to medium-sized data environments, but its limitations become increasingly apparent as accounting data volumes surge and business complexity increases.

[0003] When users search for accounting documents, they often use natural language to describe business scenarios, such as "expenses for purchasing office equipment this month" or "accounts payable that are more than 30 days old." Traditional methods cannot parse the implicit account mapping relationships (such as "office equipment" corresponding to "administrative expenses - office expenses" or "fixed assets - office equipment") and debit / credit semantics in such queries, resulting in the omission of a large number of relevant documents or the return of a large number of records irrelevant to the user's intent. The rigidity of keyword matching limits the accuracy of the search, and users must rely on professional subject coding knowledge to obtain effective results.

[0004] Existing technologies typically perform permission filtering first, then search on the filtered dataset, or search all data first and then tailor the results by role. The former, due to its overly coarse permission boundaries (often limited to first or second-level accounts), fails to accurately classify a large number of detailed account-level vouchers, potentially allowing users to access sensitive data they are not authorized to access. The latter, on the other hand, consumes excessive system resources due to its overly broad search scope, and permission tailoring may result in the loss of sorting information associated with the authorization level. For example, the results of the same query under "Administrative Expenses" and "Financial Expenses" are indiscriminately mixed, making it difficult for users to prioritize vouchers within their authorized scope according to account level importance. This design not only reduces search efficiency but also introduces data leakage risks, failing to meet the fine-grained permission isolation requirements of multi-level accounting entities (such as group-subsidiary-department). Summary of the Invention

[0005] This invention provides a method and system for intelligent retrieval and analysis of accounting data that combines AI, which can solve the problems in the prior art.

[0006] A first aspect of this invention provides an intelligent retrieval and analysis method for accounting data incorporating AI, comprising: Obtain the accounting voucher set, and jointly encode the summary, account code, debit / credit direction and transaction amount of each voucher. Generate a voucher embedding vector that integrates account semantics and debit / credit semantics. According to the multi-level permission hierarchy tree from accounting entity to detailed account, classify the vouchers into permission ownership partitions according to the account permission boundaries. Generate partition boundary embedding vectors that identify the account level for each partition. Use this to index the voucher embedding vectors of the corresponding partitions and build an account permission semantic index library. The system receives accounting retrieval queries, performs semantic parsing to generate query embedding vectors, parses user identity credentials to determine authorized account level nodes, traces from that node along a multi-level permission hierarchy tree to the root node of the accounting entity, collects account permission boundary identifiers passed through higher-level nodes, and forms a set of account authorization identifiers. Using the set of subject authorization identifiers as access credentials, the authorized subject partition that matches the set of subject authorization identifiers is located in the subject permission semantic index library. The query embedding vector and the credential embedding vector within the authorized subject partition are then subjected to cosine similarity retrieval to obtain a set of candidate results for permission isolation. For each voucher in the candidate result set, the cosine similarity between the voucher embedding vector and the query embedding vector is used as the first-level ranking factor, and the hierarchical depth of the subject permission partition to which the voucher belongs is used as the second-level decay factor. The ranking score is calculated in a comprehensive manner and the accounting voucher retrieval results are output in descending order.

[0007] The voucher is divided into permission-related partitions based on the permission boundaries of the subject, and a partition boundary embedding vector is generated for each partition to construct a subject permission semantic index library, including: For all the voucher embedding vectors within the permission-attributed partition, extract the accounting subject permission subtree topology corresponding to the partition in the multi-level permission hierarchy tree. The accounting subject permission subtree topology includes the subject hierarchy depth of each subject node in the subtree rooted at the subject node corresponding to the partition, the unique code identifier of the parent subject node, the sub-sub ... The accounting subject permission subtree topology is encoded into a fixed-length subject permission topology feature vector by the subject tree topology encoder, and the subject permission topology feature vector is used as the partition boundary embedding vector of the partition. A one-to-many index mapping table is established between the partition boundary embedding vector and the physical storage address of each voucher embedding vector within the corresponding partition. Each partition is arranged in a progressive order from shallow to deep according to the subject level depth of the subject node corresponding to its partition boundary embedding vector in the multi-level permission hierarchy tree, thus constructing a subject hierarchy index tree structure. Each non-leaf node in the subject hierarchy index tree stores the value range of the partition boundary embedding vector corresponding to all sub-partitions covered by the subject permission subtree rooted at it. Each leaf node stores the physical storage address of all voucher embedding vectors within the corresponding partition, thereby forming the subject permission semantic index library.

[0008] Parse user identity credentials to determine the authorized account level node, and trace along the multi-level permission hierarchy tree from that node to the root node of the accounting entity to collect account permission boundary identifiers, forming a set of account authorization identifiers, including: The user role label carried by the user identity credential is matched layer by layer with the set of accounting job roles associated with each subject node in the multi-level permission hierarchy tree. The matching starts from the root node of the accounting entity in the multi-level permission hierarchy tree and is traversed from top to bottom through each subject level. For each subject node in the current traversal level, query the set of accounting job roles attached to the subject node, determine whether the user role tag belongs to the set of accounting job roles, and determine the subject node that first determines the membership relationship from the root node as the user's authorized subject level node. The subject corresponding to the authorized subject level node and all its subordinate sub-sub ... Starting from the authorized subject level node, traverse upwards along the parent pointer link of the multi-level permission hierarchy tree to the root node of the accounting entity, collecting the subject permission boundary identifiers associated with each authorized subject level node and each parent subject node along the way. Arrange the subject permission boundary identifiers of the authorized subject level node at the head of the chain, and then arrange the subject permission boundary identifiers of each parent subject node in the order of traversal from near to far, forming a unidirectional ordered chain of subject permission boundary identifiers extending from the authorized subject level to the root node of the accounting entity. Use this identifier chain as the set of subject authorization identifiers.

[0009] Tracing from this node along the multi-level permission hierarchy tree to the root node of the accounting entity includes: In each jump step along the parent pointer link, the subject permission boundary identifier of the current subject node is extracted as the sub-subject identifier, and the subject permission boundary identifier of the parent subject node is extracted as the parent subject identifier. The sub-subject identifier and the parent subject identifier form a subject permission inclusion relationship pair to be verified. A matching query is performed in the subject permission inclusion relationship table that is pre-constructed offline according to the complete subject parent-child relationship of the multi-level permission hierarchy tree. Sequentially register the one-to-one direct inclusion mapping of subject permissions between the parent subject node permission boundary identifier and the permission boundary identifier of each direct child subject node on each parent-child subject connection edge. Store it in a key-value pair mapping structure, where the key is the parent subject identifier and the value is the set of all direct child subject identifiers under the parent subject. Only when there is a mapping record in the subject permission inclusion relationship table that registers the sub-subject identifier as a member of the direct sub-subject set of the parent subject identifier, will the subject permission boundary identifier of the parent subject node be included in the subject permission boundary identifier chain. This is to prevent nodes without a valid subject parent-child relationship from gaining unauthorized access to the upper-level subject level voucher data by forging subject attribution relationships.

[0010] In the subject permission semantic index, locate the partition boundary embedding vector that matches the authorized subject partition of the authorized identifier set, and perform cosine similarity retrieval between the query embedding vector and the voucher embedding vector within the authorized subject partition to obtain a candidate result set, including: The cosine similarity value between the subject permission boundary identifier and the partition boundary embedding vector of the subject partition is calculated respectively. This value is used as a similarity metric to measure whether the subject partition belongs to the subject permission jurisdiction identified by the subject permission boundary identifier in the subject permission hierarchy semantic space. For each subject permission boundary identifier, subject partitions whose cosine similarity value exceeds the preset subject partition matching threshold are selected to form a subset of matching subject partitions that uniquely corresponds to the subject permission boundary identifier. The union of the subsets of matching subject partitions corresponding to each of the subject permission boundary identifiers is obtained. All the voucher records covered by each subject partition in the union constitute the complete set of voucher data that the user can legally retrieve according to his / her subject permissions. This union is used as the authorized subject partition. Based on the physical storage address, read all the voucher embedding vectors stored in the authorized subject partition one by one. Calculate the cosine similarity between each read voucher embedding vector and the query embedding vector. Sort the voucher embedding vectors in descending order of cosine similarity from high to low. Extract the candidate voucher records that are in the first preset number of sorted positions to form the candidate result set.

[0011] The ranking score is calculated by combining the cosine similarity between the voucher embedding vector and the query embedding vector as the primary ranking factor and the hierarchical depth of the account permission partition to which the voucher belongs as the secondary decay factor. The accounting voucher retrieval results are then output in descending order, including: The first-level ranking factor is the normalized accounting document semantic similarity value after the cosine similarity between the document embedding vector corresponding to each candidate document and the query embedding vector is processed by minimum-maximum normalization. This normalization process linearly maps the original cosine similarity values ​​between different query batches to the same preset numerical range to eliminate the difference in the distribution of absolute values ​​of semantic relevance between batches. The secondary attenuation factor is the ratio of the total number of subject levels in the multi-level permission hierarchy tree to the subject level depth of the current candidate voucher's subject permission partition in the multi-level permission hierarchy tree; The comprehensive ranking score is the product of the normalized accounting voucher semantic similarity value and the secondary decay factor. This ensures that candidate vouchers whose summary semantic content is highly relevant to the query and whose subject level is relatively shallow in the multi-level permission hierarchy tree receive a higher final ranking score than candidate vouchers with similar semantic content relevance but whose subject level is relatively deep. Based on the comprehensive ranking score of each candidate voucher, they are sorted in descending order to generate a ranked sequence of accounting voucher retrieval results, which is then output.

[0012] A second aspect of this invention provides an intelligent accounting data retrieval and analysis system incorporating AI, comprising: The index building unit is used to obtain the accounting voucher set, jointly encode the summary, account code, debit / credit direction and transaction amount of each voucher, generate voucher embedding vector that integrates account semantics and debit / credit semantics, classify vouchers into permission-related partitions according to the multi-level permission hierarchy tree from accounting entity to detailed account, generate partition boundary embedding vectors that identify the account level for each partition, and use this index to index the voucher embedding vectors of the corresponding partitions to build an account permission semantic index library. The authorization identifier unit is used to receive accounting retrieval queries, generate query embedding vectors through semantic parsing, parse user identity credentials to determine authorized account hierarchical nodes, trace from this node along the multi-level permission hierarchy tree to the root node of the accounting entity, collect the account permission boundary identifiers of the higher-level nodes along the way, and form a set of account authorization identifiers. The permission retrieval unit is used to locate the authorized subject partition that matches the subject authorization identifier set in the subject permission semantic index library, using the subject authorization identifier set as the access credential. The query embedding vector is then compared with the credential embedding vector within the authorized subject partition using cosine similarity retrieval to obtain a candidate result set for permission isolation. The sorting output unit is used to calculate the sorting score for each voucher in the candidate result set, using the cosine similarity between the voucher embedding vector and the query embedding vector as the first-level sorting factor and the hierarchical depth of the subject permission partition to which the voucher belongs as the second-level decay factor, and output the accounting voucher retrieval results in descending order.

[0013] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0014] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0015] A semantic index library for account permissions is constructed, and the embedded vectors of vouchers are stored in a multi-level permission hierarchy tree partition. This allows for retrieval by performing cosine similarity matching only within the authorized partitions, significantly reducing the search scope and improving retrieval response speed. The rigid binding of permission partitions with query access vouchers prevents unauthorized access to account data, ensuring the compliance and security of accounting information in scenarios such as financial auditing and corporate internal control. The embedded vectors at partition boundaries directly identify the account level, simplifying permission verification to vector matching operations and reducing system coupling complexity.

[0016] The cosine similarity calculation between the query embedding vector generated by semantic parsing and the voucher embedding vector accurately captures the correlation between account summaries, account codes, and debit / credit semantics, avoiding ambiguity or omissions caused by traditional keyword matching. Authorized account hierarchical nodes are traced along the hierarchical tree to the root node of the accounting entity, automatically aggregating the account permission identifiers of all parent nodes along the path. No manual configuration of permission lists is required, adapting to the dynamic permission management needs of large enterprise-level multi-layered organizational structures.

[0017] The candidate result set is sorted using a combination of cosine similarity and the depth of the subject-based access control hierarchy. It prioritizes vouchers that are semantically most relevant and belong to the most detailed subject. A secondary decay factor suppresses interference from vouchers with excessively deep hierarchies and overly granular granularities, achieving a balance between relevance, access control compliance, and the accounting subject tree structure. This improves the efficiency of human-computer interaction for finance personnel searching for vouchers. This mechanism directly outputs descending-order results with access control isolation, eliminating the need for secondary backend filtering and ensuring data isolation throughout the retrieval process. Attached Figure Description

[0018] Figure 1 A flowchart illustrating the process of intelligent retrieval and analysis of accounting data using AI. Figure 2 This is a diagram illustrating the results of accounting document retrieval. Figure 3 A schematic diagram of the structure of an AI-integrated intelligent accounting data retrieval and analysis system; Figure 4 This is a schematic diagram of a multi-level permission hierarchy tree topology. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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 a part of the embodiments of the present invention, and not all of them. 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.

[0020] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0021] Figure 1 This is a flowchart illustrating the AI-integrated intelligent accounting data retrieval and analysis method according to an embodiment of the present invention. The AI-integrated intelligent accounting data retrieval and analysis method includes: Obtain the accounting voucher set, and jointly encode the summary, account code, debit / credit direction and transaction amount of each voucher. Generate a voucher embedding vector that integrates account semantics and debit / credit semantics. According to the multi-level permission hierarchy tree from accounting entity to detailed account, classify the vouchers into permission ownership partitions according to the account permission boundaries. Generate partition boundary embedding vectors that identify the account level for each partition. Use this to index the voucher embedding vectors of the corresponding partitions and build an account permission semantic index library. The system receives accounting retrieval queries, performs semantic parsing to generate query embedding vectors, parses user identity credentials to determine authorized account level nodes, traces from that node along a multi-level permission hierarchy tree to the root node of the accounting entity, collects account permission boundary identifiers passed through higher-level nodes, and forms a set of account authorization identifiers. Using the set of subject authorization identifiers as access credentials, the authorized subject partition that matches the set of subject authorization identifiers is located in the subject permission semantic index library. The query embedding vector and the credential embedding vector within the authorized subject partition are then subjected to cosine similarity retrieval to obtain a set of candidate results for permission isolation. For each voucher in the candidate result set, the cosine similarity between the voucher embedding vector and the query embedding vector is used as the first-level ranking factor, and the hierarchical depth of the subject permission partition to which the voucher belongs is used as the second-level decay factor. The ranking score is calculated in a comprehensive manner and the accounting voucher retrieval results are output in descending order.

[0022] The accounting voucher set comes from the voucher library, ledger library, and report library in the enterprise financial management system, ERP system, or dedicated accounting software. Each accounting data record corresponds to a specific accounting transaction. A typical accounting data record includes the following core fields: Voucher Identifier, used to uniquely identify the voucher number or transaction number of the record in the source system; Account Code, recording the accounting account code involved in the transaction, such as asset account 1001 (cash on hand), expense account 6602 (business entertainment expenses), etc., the account code follows the account system stipulated by enterprise accounting standards; Summary Text, describing the specific content of the transaction in natural language, such as "payment for office supplies purchases in the first quarter of 2024" or "received payment from customer A company"; Amount Field, recording the debit and credit amounts of the transaction, measured in currency units (such as RMB yuan); Timestamp, identifying the date of occurrence or posting of the transaction, accurate to the day or second; Authority Node Identifier, recording the authority node number to which the accounting data record belongs in the multi-level authority hierarchy tree. This identifier is automatically generated during data entry based on the department, cost center, or accounting entity where the transaction occurred, and is used as the basis for subsequent authority partitioning.

[0023] In addition to the core fields mentioned above, accounting data records may also include auxiliary accounting fields, such as multi-dimensional auxiliary information like department, project, and counterparty dimensions, as well as attachment identifiers for linking electronic scans or image documents. After data collection, joint semantic encoding is performed on each accounting data record. The joint semantic encoding process fuses text fields (summary text, account name) with structured fields (account code, amount range, timestamp). Specifically, the summary text is encoded into a text semantic vector using a pre-trained language model (such as BERT or a domain-fine-tuned financial text encoder), the account code is mapped into an account semantic vector through an embedding layer, the amount field is mapped into an amount feature vector after log normalization, and the timestamp is converted into a time feature vector through periodic encoding (such as sine and cosine position encoding). The above-mentioned dimensional vectors are concatenated or weighted and summed according to predefined weights to form a fixed-dimensional accounting semantic vector. Let the dimension of the text semantic vector be d. t The semantic vector dimension of the subject is d. s The dimension of the monetary feature vector is d. a The time feature vector has a dimension of d. m Then the dimension of the accounting semantic vector is d. c = d t + d s + d a + d m The accounting semantic vector is then used in the subsequent retrieval stage to perform cosine similarity calculation with the query semantic vector, thereby achieving semantic matching and retrieval of accounting data records.

[0024] Through the above preprocessing, each record in the accounting voucher set completes the mapping from raw structured data to a high-dimensional semantic vector, while retaining the identifier of its respective permission node. This lays the data foundation for subsequent partitioning according to a multi-level permission hierarchy tree and the construction of a distributed semantic index. For large-scale accounting datasets containing millions to tens of millions of records, a distributed batch processing framework can be used to parallelize the accounting semantic vector encoding task, significantly reducing preprocessing time.

[0025] The voucher is divided into permission-related partitions based on the permission boundaries of the subject, and a partition boundary embedding vector is generated for each partition to construct a subject permission semantic index library, including: For all the voucher embedding vectors within the permission-attributed partition, extract the accounting subject permission subtree topology corresponding to the partition in the multi-level permission hierarchy tree. The accounting subject permission subtree topology includes the subject hierarchy depth of each subject node in the subtree rooted at the subject node corresponding to the partition, the unique code identifier of the parent subject node, the sub-sub ... The accounting subject permission subtree topology is encoded into a fixed-length subject permission topology feature vector by the subject tree topology encoder, and the subject permission topology feature vector is used as the partition boundary embedding vector of the partition. A one-to-many index mapping table is established between the partition boundary embedding vector and the physical storage address of each voucher embedding vector within the corresponding partition. Each partition is arranged in a progressive order from shallow to deep according to the subject level depth of the subject node corresponding to its partition boundary embedding vector in the multi-level permission hierarchy tree, thus constructing a subject hierarchy index tree structure. Each non-leaf node in the subject hierarchy index tree stores the value range of the partition boundary embedding vector corresponding to all sub-partitions covered by the subject permission subtree rooted at it. Each leaf node stores the physical storage address of all voucher embedding vectors within the corresponding partition, thereby forming the subject permission semantic index library.

[0026] After generating the voucher embedding vectors and performing initial partitioning according to account permission boundaries, it is necessary to further refine the structural features of each permission-assigned partition to efficiently locate the authorized partition during subsequent retrieval. For each permission-assigned partition, firstly, all voucher embedding vectors within the partition are traversed, and simultaneously, the accounting account permission subtree topology corresponding to the partition is extracted from the multi-level permission hierarchy tree. The accounting account permission subtree topology refers to the complete subtree structure information extending downwards from the corresponding account node of the partition as the root node. Specifically, it includes the account hierarchy depth of each account node in the subtree, the unique code identifier of the parent account node, the sequence of sub-account nodes arranged in ascending order of account code, and the account hierarchy path length of each sub-account node relative to the subtree root node. These four types of information describe the topological form of the subject permission subtree from different dimensions: the subject level depth reflects the absolute position of the node in the entire multi-level permission hierarchy tree; the unique code identifier of the parent subject node ensures the unique traceability of the node's affiliation; the sub-subject node sequence sorted by subject code fixes the relative order between sibling nodes, thereby eliminating coding ambiguity caused by different traversal orders; and the subject level path length quantifies the structural distance between each child node and the partition root node.

[0027] After organizing the above four types of topological information, the entire accounting subject permission subtree topology is mapped into a fixed-length subject permission topological feature vector through a subject tree topology encoder. The design goal of the subject tree topology encoder is to compress the irregular tree structure into a fixed-length dense vector, while preserving key topological semantics such as node hierarchy, parent-child relationship, and sibling node order. Specifically, the encoder uses the level depth of each subject node, the hash embedding of the parent node's encoding, and the sequence position encoding of the child node as initial node features. It aggregates the structural information of each node within the subtree through several layers of message passing, and finally performs global pooling on the hidden layer representation of the subtree root node, outputting a fixed-dimensional subject permission topological feature vector. Alternatively, a recursive neural network-based approach can be used. The subtree topology is serialized according to a depth-first traversal order. The level depth, parent node identifier, and path length of each node are concatenated into a node feature vector, which is then sequentially input into the recursive unit. The final hidden state is taken as the subject permission topological feature vector. Regardless of the encoding scheme used, the generated subject permission topological feature vector serves as the partition boundary embedding vector for that partition, representing the unique identifier of that partition in the subject permission semantic space.

[0028] After obtaining the partition boundary embedding vectors for each partition, a one-to-many index mapping table is established, mapping the partition boundary embedding vectors to the physical storage addresses of all credential embedding vectors within that partition. The structure of this one-to-many index mapping table is as follows: the identifier of the partition boundary embedding vector is used as the key, and the list of physical addresses of all credential embedding vectors within that partition in the underlying storage medium is used as the value. This design allows for the direct batch loading of credential embedding vectors within a partition after locating it during the retrieval phase, avoiding the performance overhead of a full database scan.

[0029] After the one-to-many index mapping table is established, all partitions are arranged in ascending order of subject level depth in the multi-level permission hierarchy tree according to the subject nodes corresponding to their partition boundary embedding vectors, thus constructing a subject-level index tree structure. The subject-level index tree is an index tree that maintains a hierarchical correspondence with the multi-level permission hierarchy tree, and its hierarchical order strictly follows the increasing direction of the depth value of the subject nodes in the original permission hierarchy tree. Non-leaf nodes in the subject-level index tree store the value range of the partition boundary embedding vectors corresponding to all sub-partitions covered by the subject permission subtree rooted at that non-leaf node. The value range is determined by collecting the partition boundary embedding vectors of all sub-partitions below the non-leaf node, taking the minimum and maximum values ​​for each dimension, forming a super-rectangular bounding box, which serves as the value range stored for that non-leaf node. This design borrows the interval pruning idea from R-trees in spatial indexing, allowing irrelevant subtree branches to be quickly excluded during the retrieval phase by determining whether the query vector falls within the value range of a non-leaf node, significantly reducing the number of partitions requiring precise similarity calculations.

[0030] The leaf nodes of the subject-level index tree correspond one-to-one with specific partitions. Each leaf node stores the physical storage address of all voucher embedding vectors within that partition, which is consistent with the address list corresponding to that partition in the one-to-many index mapping table. By directly holding the physical address through the leaf node, the retrieval process can immediately initiate a batch read operation of the underlying storage after locating the target leaf node, without needing to go through an additional address lookup step.

[0031] The subject-level index tree is responsible for efficient hierarchical pruning and authorization range positioning at the partition granularity, while the one-to-many index mapping table is responsible for fast physical loading of credential embedding vectors within the partition. The two work together to enable the entire index library to support both access filtering based on subject permission boundaries and efficient vector similarity retrieval within authorized partitions.

[0032] In actual construction, when the accounting entity's account system changes (such as adding detailed accounts or adjusting account affiliation), it is only necessary to re-extract the accounting account permission subtree topology for the affected partitions, update the corresponding partition boundary embedding vectors, and update the value ranges of relevant non-leaf nodes in the account hierarchical index tree, without having to rebuild the entire index. This partial update mechanism ensures the maintainability of the index in scenarios with dynamic changes in the account system. For large enterprise accounting systems with deep account hierarchies and a large number of sub-account nodes, the number of levels in the account hierarchical index tree increases accordingly, and the coverage of the value ranges of non-leaf nodes also expands accordingly. However, since the pruning effect of each level accumulates with the increase in level depth, the overall retrieval efficiency can still be kept within an acceptable range. Through the above complete partition boundary embedding vector generation process and account hierarchical index tree construction mechanism, the account permission semantic index library can achieve efficient semantic retrieval support for large-scale accounting voucher sets while ensuring the semantic correctness of permission isolation.

[0033] Parse user identity credentials to determine the authorized account level node, and trace along the multi-level permission hierarchy tree from that node to the root node of the accounting entity to collect account permission boundary identifiers, forming a set of account authorization identifiers, including: The user role label carried by the user identity credential is matched layer by layer with the set of accounting job roles associated with each subject node in the multi-level permission hierarchy tree. The matching starts from the root node of the accounting entity in the multi-level permission hierarchy tree and is traversed from top to bottom through each subject level. For each subject node in the current traversal level, query the set of accounting job roles attached to the subject node, determine whether the user role tag belongs to the set of accounting job roles, and determine the subject node that first determines the membership relationship from the root node as the user's authorized subject level node. The subject corresponding to the authorized subject level node and all its subordinate sub-sub ... Starting from the authorized subject level node, traverse upwards along the parent pointer link of the multi-level permission hierarchy tree to the root node of the accounting entity, and collect the authorized subject level node and the subject permission boundary identifier associated with each of the parent subject nodes along the way. The account permission boundary identifiers of the authorized account level node are arranged at the head of the chain, and then the account permission boundary identifiers of each superior account node are arranged in traversal order from near to far, forming a chain of account permission boundary identifiers that extends unidirectionally and orderly from the authorized account level to the root node of the accounting entity. This identifier chain is used as the set of account authorization identifiers.

[0034] The user role tag carried in the user identity credential is the core input information for permission matching. In actual accounting scenarios, a user may simultaneously hold multiple job roles; for example, an employee may hold both the "cashier" and "accounts payable specialist" role tags. Each account node in the multi-level permission hierarchy is pre-associated with a set of accounting job roles. This set records which job roles are authorized to access the account node and its subordinate sub-accounts. The matching process starts from the root node of the accounting entity and proceeds layer by layer from top to bottom according to the tree's hierarchical structure. Multiple account nodes within the same level can be queried in parallel to improve traversal efficiency.

[0035] For each subject node in the current traversal level, the set of accounting roles attached to that node is retrieved, and each role in the user role tag set is checked to see if it belongs to that role set. The judgment logic uses set intersection: if the intersection of the user role tag set and the accounting role set of the subject node is not empty, then the membership relationship is considered to be valid. The reason for using the root node of the accounting entity as the starting point for matching is that the root node has the highest level. If a user's role is matched at the root node level, it means that the user has access to all accounting subjects and belongs to a high-privilege account; if the root node is not matched, the process continues to the next level until the first matching node is found. The subject node from the root node where the membership relationship is first determined to be valid is identified as the user's authorized subject level node. The subject corresponding to this node, together with all its subordinate sub-sub-subjects, constitutes the user's subject access permission scope. This "first match and it's over" strategy ensures the uniqueness and certainty of the permission boundary and avoids the problem of ambiguous permission scope caused by multiple levels of simultaneous matching.

[0036] Let's illustrate this with a specific scenario: Assume a multi-level permission hierarchy tree has four levels: the accounting entity root node, first-level subject nodes (such as "Liabilities" and "Assets"), second-level subject nodes (such as "Accounts Payable" and "Prepaid Accounts"), and third-level detailed subject nodes. A user holds the role tag "Accounts Payable Specialist". Traversing from the root node, the role set attached to the root node is {"Finance Director", "General Ledger Accountant"}, the intersection is empty, so no match is found. Entering the second level, the "Liabilities" node is attached to the role set {"Liabilities Supervisor", "Accounts Payable Specialist"}, the intersection is not empty, the membership relationship is established. At this point, the "Liabilities" node is determined as the user's authorized subject level node, and the user's subject access permission scope is "Liabilities" and all its sub-sub ...

[0037] After determining the authorized account level nodes, the system traverses upwards along the parent pointer link of the multi-level permission hierarchy tree from that node to the root node of the accounting entity, collecting the account permission boundary identifiers associated with each node along the way. The account permission boundary identifier is a unique identifier generated for each account node during the construction of the account permission semantic index. Its encoding rule integrates account level location information and account semantic information, enabling rapid location of the corresponding partition boundary embedding vector during the index retrieval stage. The parent pointer link is a directed pointer from each non-root node in the multi-level permission hierarchy tree to its direct parent node. By following the parent pointers level by level, it is possible to backtrack from any node to the root node. The entire backtracking path constitutes an ordered sequence of nodes from the authorized account level node to the root node.

[0038] When collecting account permission boundary identifiers, the account permission boundary identifier of the authorized account level node itself is placed at the head of the sequence chain. Then, according to the order of traversal of the parent pointer, the account permission boundary identifiers of each parent account node along the way are arranged at the end of the chain, from nearest to farthest, until the account permission boundary identifier of the accounting entity root node is appended to the end of the chain. Using the above scenario, the identifiers of "liability" nodes are arranged at the head of the chain, and the identifiers of their parent root nodes are arranged at the tail of the chain, forming an ordered identifier chain of length 2. If the authorized account level node is located at the third level, the identifier chain length is 3, containing the identifiers of the third-level node, the corresponding second-level node, and the root node in sequence.

[0039] This chain of account permission boundary identifiers, extending unidirectionally and orderly from the authorized account level to the root node of the accounting entity, constitutes the final set of account authorization identifiers. Its ordered nature has significant retrieval semantics: the identifier at the head of the chain represents the finest-grained boundary of user permissions, while the identifier at the tail represents the coarsest-grained global boundary of the accounting entity. In the subsequent process of locating authorized account partitions using the set of account authorization identifiers as access credentials, the account level identifier information contained in the partition boundary embedding vector will match this identifier chain. Only when the account level node identified by the partition boundary embedding vector appears in this identifier chain is the corresponding partition included in the authorized account partition, thus achieving precise permission isolation retrieval.

[0040] The ordered arrangement of the identifier chain also supports rapid determination of permission scope. When it is necessary to verify whether a specific subject partition is within the user's permission scope, it is only necessary to check whether the subject permission boundary identifier of that partition matches any element in the identifier chain to complete the determination. There is no need to re-traverse the permission hierarchy tree, which significantly reduces the computational overhead of permission verification during the retrieval phase. In concurrent retrieval scenarios, the set of subject authorization identifiers can be cached in the session context after the user's identity credential is parsed. Multiple query requests within the same session can directly reuse this identifier set, avoiding repeated execution of permission hierarchy tree traversal operations, further improving the system's retrieval response efficiency.

[0041] If a user's role tag is not matched with any subject node in the entire permission hierarchy tree, the user is considered to have no access permissions for any subject, the set of subject authorization identifiers is empty, and an empty result set will be returned in subsequent retrieval stages. If the user's role tag is matched at the root node level, the identifier chain only contains the subject permission boundary identifiers of the root node, and the corresponding authorized subject partitions cover all subject partitions. The retrieval is not limited by the subject hierarchy and is suitable for the global voucher retrieval needs of high-privilege accounts such as CFOs.

[0042] Tracing from this node along the multi-level permission hierarchy tree to the root node of the accounting entity includes: In each jump step along the parent pointer link, the subject permission boundary identifier of the current subject node is extracted as the sub-subject identifier, and the subject permission boundary identifier of the parent subject node is extracted as the parent subject identifier. The sub-subject identifier and the parent subject identifier form a subject permission inclusion relationship pair to be verified. A matching query is performed in the subject permission inclusion relationship table that is pre-constructed offline according to the complete subject parent-child relationship of the multi-level permission hierarchy tree. Sequentially register the one-to-one direct inclusion mapping of subject permissions between the parent subject node permission boundary identifier and the permission boundary identifier of each direct child subject node on each parent-child subject connection edge. Store it in a key-value pair mapping structure, where the key is the parent subject identifier and the value is the set of all direct child subject identifiers under the parent subject. Only when there is a mapping record in the subject permission inclusion relationship table that registers the sub-subject identifier as a member of the direct sub-subject set of the parent subject identifier, will the subject permission boundary identifier of the parent subject node be included in the subject permission boundary identifier chain. This is to prevent nodes without a valid subject parent-child relationship from gaining unauthorized access to the upper-level subject level voucher data by forging subject attribution relationships.

[0043] During the upward tracing process along the multi-level permission hierarchy tree, each jump from a sub-subject node to a parent subject node is considered an independent jump step. At the execution of each jump step, the subject permission boundary identifier is extracted from the metadata of the current subject node and recorded as the sub-subject identifier; simultaneously, the corresponding subject permission boundary identifier is extracted from the metadata of its direct parent subject node and recorded as the parent subject identifier. This constitutes a subject permission inclusion relationship pair to be verified, namely an ordered binary tuple composed of the sub-subject identifier and the parent subject identifier, used for precise matching in subsequent legality checks. The core of this design is that each jump in the tracing path does not directly trust the node's self-declared ownership relationship, but instead entrusts it to an independently constructed subject permission inclusion relationship table for verification, fundamentally cutting off unauthorized access paths that rely on node self-declaration.

[0044] The subject permission inclusion relationship table is built offline before system runtime, based on the complete parent-child relationship of a multi-level permission hierarchy tree. During construction, each parent-child subject connection edge in the hierarchy tree is traversed, and the subject permission boundary identifier of the parent subject node and the subject permission boundary identifier of its direct child subject nodes are extracted for each edge. The correspondence between these two is then recorded in the table as a one-to-one direct inclusion mapping of subject permissions. The entire table is stored using a key-value pair mapping structure, where the key is the parent subject identifier, and the values ​​are the set of identifiers of all direct child subjects under that parent subject. For example, if a first-level subject node directly governs three second-level detailed subjects in the hierarchy tree, then the first-level subject identifier serves as the key, and its value set contains the identifiers of the three second-level detailed subjects. Furthermore, the membership relationships in the set strictly adhere to the original topology of the hierarchy tree and cannot be dynamically added or modified at runtime. This offline pre-construction method ensures the read-only nature of the subject permission inclusion relationship table during the query phase, eliminating the risk of runtime data tampering.

[0045] During the verification phase of each jump step, a matching query is performed in the subject permission inclusion relationship table using the parent subject identifier extracted in the current jump step as the key. This retrieves the set of direct sub-sub ...

[0046] From a practical application perspective, consider a permission hierarchy tree with a four-layer structure: accounting entity root node, primary account node, secondary account node, and detailed account node. When a user is authorized to access a detailed account node, the tracing process starts from that detailed account node. The first step extracts the detailed account identifier as a sub-account identifier and the secondary account identifier as a parent account identifier. The system queries the account permission inclusion relationship table using the secondary account identifier as the key to retrieve its direct sub-account set. After confirming the detailed account identifier exists in this set, the secondary account identifier is added to the identifier chain. The second step extracts the secondary account identifier as a sub-account identifier and the primary account identifier as a parent account identifier, performing the same matching query. After confirming its validity, the primary account identifier is added to the identifier chain. The third step uses the primary account identifier as the sub-account identifier and the accounting entity root node identifier as the parent account identifier to complete the final verification, adding the root node identifier to the identifier chain. After the entire tracing process is completed, the collected identifier chains constitute a complete set of account authorization identifiers, used for subsequent partition location and voucher retrieval.

[0047] If, during the aforementioned tracing process, the relationship between the sub-subject identifier and the parent subject identifier at a certain jump step does not have a corresponding record in the subject permission inclusion relationship table, it indicates that the node's claim of ownership to its superior node is invalid. This situation may be triggered by various reasons, including tampering with the subject hierarchy information in the user's identity credentials, illegal modification of the hierarchy tree structure during runtime, or forgery of ownership across normal parent-child boundaries. Regardless of the reason, as soon as the matching query fails, the tracing is terminated, and the collected identifier chain is truncated to the result of the previous valid jump step, thereby ensuring that every identifier in the subject authorization identifier set has undergone strict legality verification.

[0048] Key-value mapping structures are typically organized using hash tables at the engineering implementation level, with the hash value of the parent account identifier as the index. This allows for key location in constant time, and the attribution of sub-account identifiers is then determined through set member queries. Since the account permission relationship table is loaded in read-only mode after offline construction, multiple concurrent trace queries can safely share the same table structure without locking, thus maintaining stable query performance in high-concurrency accounting retrieval scenarios. For large account hierarchical trees, the table structure can be further cached hierarchically, prioritizing the loading of sub-account sets corresponding to high-frequency parent account identifiers near the root node into memory to reduce access latency during deep traces.

[0049] The offline construction frequency of the account permission inclusion table is synchronized with the update cycle of the hierarchical tree. When an accounting entity adds an account, adjusts the account hierarchy, or removes an account node, the updated hierarchical tree must be traversed again to fully rebuild the account permission inclusion table. After the reconstruction is complete and the consistency check passes, the old table is switched to the new table atomically. This avoids inconsistencies in permission judgments caused by mixing the old and new tables during the switchover process. This atomic replacement mechanism ensures that the traceability verification process is always based on a consistent permission topology state when the account hierarchy structure changes, and will not produce incorrect legality judgments due to intermediate states of the table structure.

[0050] In the subject permission semantic index, locate the partition boundary embedding vector that matches the authorized subject partition of the authorized identifier set, and perform cosine similarity retrieval between the query embedding vector and the voucher embedding vector within the authorized subject partition to obtain a candidate result set, including: The cosine similarity value between the subject permission boundary identifier and the partition boundary embedding vector of the subject partition is calculated respectively. This value is used as a similarity metric to measure whether the subject partition belongs to the subject permission jurisdiction identified by the subject permission boundary identifier in the subject permission hierarchy semantic space. For each subject permission boundary identifier, subject partitions whose cosine similarity value exceeds the preset subject partition matching threshold are selected to form a subset of matching subject partitions that uniquely corresponds to the subject permission boundary identifier. The union of the subsets of matching subject partitions corresponding to each of the subject permission boundary identifiers is obtained. All the voucher records covered by each subject partition in the union constitute the complete set of voucher data that the user can legally retrieve according to his / her subject permissions. This union is used as the authorized subject partition. Based on the physical storage address, read all the voucher embedding vectors stored in the authorized subject partition one by one. Calculate the cosine similarity between each read voucher embedding vector and the query embedding vector. Sort the voucher embedding vectors in descending order of cosine similarity from high to low. Extract the candidate voucher records that are in the first preset number of sorted positions to form the candidate result set.

[0051] In the retrieval process of the subject permission semantic index, the core challenge lies in how to accurately map the set of subject authorization identifiers held by users to the partition structure of physical storage, thereby ensuring both strict permission isolation and maintaining retrieval efficiency. To this end, a partition matching mechanism based on cosine similarity is adopted as a semantic implementation method for permission filtering.

[0052] Specifically, for each subject permission boundary identifier in the subject authorization identifier set, cosine similarity is calculated sequentially with all registered partition boundary embedding vectors in the subject permission semantic index. The partition boundary embedding vectors are encoded as high-dimensional dense vectors fusing subject-level path semantics and permission boundary semantics during the database construction phase. Similarly, the subject permission boundary identifiers are projected into the same embedding space after semantic parsing. Therefore, the cosine similarity between the two can effectively measure whether a subject partition falls within the scope of the permission represented by the identifier in the subject permission-level semantic space. A higher cosine similarity value indicates that the semantic features of the subject partition are closer to the permission coverage described by the permission boundary identifier, and it is more likely to belong to the legitimate jurisdiction of that permission. Let the embedding vector corresponding to the subject permission boundary identifier be... The partition boundary embedding vector of a certain subject partition is: Then the cosine similarity between the two The calculation is as follows: .

[0053] The similarity value range is In the actual subject permission semantic space, since the embedding vectors have all undergone normalization processing, The effective range usually falls within Within the range.

[0054] After obtaining the cosine similarity value between each subject's permission boundary identifier and all subject partitions, a preset subject partition matching threshold is set. For each subject permission boundary identifier, filter out all those that meet the requirements. The subject partitions constitute a subset of matching subject partitions that uniquely correspond to the subject's permission boundary identifier. Threshold The settings directly affect the balance between the precision and recall of permission filtering: if Setting the limit too high may miss some legitimate partitions that semantically belong to the scope of the permission but have slight deviations in the embedding representation, resulting in an undue narrowing of the authorized search scope; if Setting the permissions too low may introduce partitions that do not fall under the jurisdiction of that permission, leading to the risk of permission violations. In actual deployments, It can be adaptively adjusted according to the scale of the account system and the granularity of permissions of different accounting entities. Usually, the optimal value is determined by statistical analysis of partition samples with known permission ownership relationships during the system initialization phase.

[0055] Perform a set union operation on the subsets of matching account partitions corresponding to each account permission boundary identifier, merging all subsets into a unified set of authorized account partitions. The physical meaning of this union is: the sum of all account partitions that the current user can legally access based on their account permission hierarchy nodes and all parent nodes traced back to the root node of the accounting entity. All voucher records covered by each account partition in the union constitute the complete set of voucher data that the user can legally access according to their permissions in this search. This union operation ensures the integrity of permissions: when a user holds permissions for multiple levels of nodes in a multi-level permission hierarchy tree, all legal partitions corresponding to each level of node are included in the search scope, preventing the omission of some legal partitions due to the independent processing of permission identifiers.

[0056] After determining the scope of the authorized subject partitions, based on the physical storage addresses recorded in the index database for each partition, all voucher embedding vectors stored within each authorized subject partition are read one by one. The physical storage addresses are bound to the partition boundary embedding vectors and written into the index structure during the database creation phase; therefore, the corresponding vector storage block can be directly located through the partition identifier, eliminating the need for a full database scan and significantly reducing I / O overhead. For each read voucher embedding vector, its cosine similarity to the query embedding vector is calculated. Let the query embedding vector be... The embedding vector of a certain certificate is Then the cosine similarity between the two is for: .

[0057] This similarity value reflects the degree of semantic matching between the voucher and the retrieval query, integrating the comprehensive relevance of summary text semantics, subject coding semantics, loan direction semantics, and transaction amount semantics.

[0058] After calculating the cosine similarity between the embedded vectors of all vouchers within the authorized subject partition and the query embedded vector, then... The data is sorted in descending order of value, and candidate voucher records at the top of the sorted positions (within a predetermined number of positions) are selected to form a candidate result set. The predetermined number of records needs to be set considering both the computational cost of subsequent sorting stages and the sufficiency of the result set's coverage. It is typically set to a fixed integer upper limit, for example, in medium-sized accounting data scenarios, it can be set to a number of tens to hundreds of candidates to achieve a reasonable balance between retrieval accuracy and response latency. Each voucher record in the candidate result set carries not only a cosine similarity value... It also retains the hierarchical depth information of the subject permission partitions to which it belongs, for use in the subsequent comprehensive sorting stage.

[0059] The entire partitioning and candidate set generation process is strictly executed within the permission boundaries. The credential embedding vectors in subject partitions that are not included in the union will not participate in any similarity calculation, fundamentally eliminating the possibility of cross-permission data leakage and realizing a deep integration of semantic retrieval and permission isolation.

[0060] The ranking score is calculated by combining the cosine similarity between the voucher embedding vector and the query embedding vector as the primary ranking factor and the hierarchical depth of the account permission partition to which the voucher belongs as the secondary decay factor. The accounting voucher retrieval results are then output in descending order, including: The first-level ranking factor is the normalized accounting document semantic similarity value after the cosine similarity between the document embedding vector corresponding to each candidate document and the query embedding vector is processed by minimum-maximum normalization. This normalization process linearly maps the original cosine similarity values ​​between different query batches to the same preset numerical range to eliminate the difference in the distribution of absolute values ​​of semantic relevance between batches. The secondary attenuation factor is the ratio of the total number of subject levels in the multi-level permission hierarchy tree to the subject level depth of the current candidate voucher's subject permission partition in the multi-level permission hierarchy tree; The comprehensive ranking score is the product of the normalized accounting voucher semantic similarity value and the secondary decay factor, so that candidate vouchers whose summary semantic content is highly relevant to the query and whose subject level is shallower in the multi-level permission hierarchy tree receive a higher final ranking score than candidate vouchers with similar semantic content relevance but whose subject level is deeper. Based on the comprehensive ranking score of each candidate voucher, they are sorted in descending order to generate and output a sequence of ranked accounting voucher retrieval results.

[0061] After obtaining the candidate result set with access restrictions, the candidate vouchers need to be comprehensively ranked to prioritize presenting the most semantically relevant vouchers with the most suitable subject level to the querying user. The ranking mechanism adopts a two-level factor design: the first-level ranking factor characterizes the semantic fit between the candidate voucher and the query intent, while the second-level attenuation factor introduces subject level depth information to appropriately reduce the weight of vouchers located deeper in the multi-level access permission hierarchy tree, thereby achieving a balance between semantic relevance and subject level rationality in the search results.

[0062] The calculation of the primary ranking factor is based on cosine similarity, but the original cosine similarity value is not directly used in the synthesis of the final ranking score. This is because the candidate sets generated by different query batches exhibit significant differences in the absolute value distribution of semantic relevance: in some query batches, the overall cosine similarity between candidate vouchers and query embedding vectors is relatively high, while in others it is relatively low. Directly comparing across batches using the original cosine similarity value or multiplying it with a decay factor would cause the ranking result to be affected by batch distribution shifts and lose stability. To eliminate this difference in the absolute value distribution of semantic relevance between batches, the original cosine similarity values ​​of all candidate vouchers within the same query batch are subjected to min-max normalization, linearly mapping them to the same preset numerical range. Let the first-order cosine similarity value in the candidate set of the current query batch be... The original cosine similarity value of the vouchers is The minimum cosine similarity within the candidate set is The maximum value is The lower bound of the preset numerical range is The upper boundary is Then the normalized semantic similarity value of accounting vouchers for: .

[0063] When all credentials in the candidate set have the same cosine similarity (i.e.) To avoid division by zero exceptions, during division by zero, the following should be uniformly used: The value is assigned to the midpoint of a preset numerical range. The preset numerical range is usually set to... At this point, the normalization formula degenerates into a standard minimum-maximum normalized form, which facilitates direct multiplication with the second-order attenuation factor. After normalization, That is, as the first The value of the primary ranking factor for each candidate voucher reflects only the relative semantic relevance of the voucher within the current batch of candidate vouchers, rather than the absolute relevance across batches, thus ensuring that the ranking results are consistently comparable across different query scenarios.

[0064] The design of the secondary attenuation factor relies on the hierarchical depth information of the multi-level permission hierarchy tree. The multi-level permission hierarchy tree is rooted at the accounting entity and expands downwards sequentially to each level of account node until the detailed account leaf node. Each node has a specific hierarchical depth number in the tree. Let the total number of account levels in the multi-level permission hierarchy tree be... , No. The subject permission partition to which the candidate voucher belongs has a subject hierarchy depth of [depth] in this multi-level permission hierarchy tree. Then the secondary decay factor corresponding to this certificate Defined as: .

[0065] when When the level is small, it indicates that the account level to which the voucher belongs is relatively shallow in the access hierarchy tree, and is close to the root node of the accounting entity. The larger the value, the weaker the attenuation effect on the overall ranking score; when A larger value indicates that the account to which the voucher belongs is a more granular detailed account, located at a deeper level. The smaller the weight, the stronger the attenuation of the overall ranking score. The business logic behind this design is that, in accounting retrieval scenarios, vouchers with similar abstract semantics, if belonging to shallower-level accounts (such as primary or secondary accounts), usually have higher general reference value. However, vouchers belonging to extremely fine-grained detailed accounts, although highly relevant under specific queries, have a narrower scope of application and should be appropriately weighted in the overall ranking to avoid over-focusing on a particular detailed account partition.

[0066] Comprehensive ranking score The product of the first-order factor and the second-order decay factor: ; because It has been normalized to a preset numerical range, and The range of values ​​is (when Take the minimum value ,when Take the maximum value at time However, in actual business and The principle of constancy holds true, therefore ), comprehensive ranking score The size is influenced by both semantic relevance and hierarchical depth. For a summary whose semantic content is highly relevant to the query (…),… (Larger) and the subject level it belongs to is relatively shallow in the multi-level permission hierarchy tree ( Smaller Larger) candidate certificates, The value is significantly higher than that of candidate credentials with similar semantic content but belonging to a deeper subject level, thus obtaining a higher position in the descending order.

[0067] In the actual sorting process, each candidate document in the candidate result set is calculated separately. and Then synthesize according to the above formula. Subsequently based on The values ​​are sorted in descending order for all candidate vouchers. When two vouchers... When values ​​are the same, the voucher entry timestamp can be introduced as an additional sorting key to prioritize the output of vouchers with more recent times, ensuring the determinism of the sorting results. After sorting, a sorted sequence of accounting voucher retrieval results is generated and output. Each record in the sequence contains the original voucher information (summary, account code, debit / credit direction, transaction amount) and its corresponding comprehensive sorting score. This is provided for display and secondary filtering by upper-level applications or user interfaces.

[0068] At the engineering implementation level, normalization and attenuation factor calculations can be performed in batches using a vectorized approach after candidate set retrieval, eliminating the need for sequential calculations and resulting in high computational efficiency. For scenarios with large candidate sets, the subject hierarchy depth can be pre-stored in the subject permission semantic index library by embedding a vector for each voucher. This field is included when retrieving the candidate set, avoiding repeated queries of the hierarchical tree structure during the sorting stage, thus reducing the additional overhead of the sorting stage. The overall sorting process is seamlessly integrated with the permission-isolated retrieval process, ensuring that the final output sequence of accounting voucher retrieval results meets the business needs of actual accounting data retrieval in terms of permission compliance, semantic relevance, and reasonable account hierarchy.

[0069] like Figure 2 As shown, Figure 2 The system's final output of accounting voucher retrieval results is displayed. The sequence is strictly arranged in descending order based on the comprehensive ranking score, perfectly balancing semantic relevance and the rationality of the account hierarchy. For example, voucher V_A001, ranked first, received the highest score of 4.00 due to its extremely high normalized semantic similarity (1.00) and its belonging to a first-level account (the shallowest level with the weakest attenuation), and was therefore prioritized by the system as having extremely high general reference value. Conversely, V_A006, although having a semantic similarity as high as 0.95, belongs to a very fine-grained fourth-level detailed account with a narrower scope of application. After being heavily weighted by the attenuation factor, its score is only 0.95, placing it at the bottom. Particularly noteworthy are V_A002, ranked third, and V_A004, ranked fourth. Both have a comprehensive ranking score of 1.00, and the system automatically introduces the "voucher entry timestamp" as an additional sorting key. Since V_A002 was entered more recently (July 15, 2025) than V_A004 (July 12, 2025), V_A002 was output first, ensuring the absolute certainty of the sorting results. The table also fully outputs the original information, including voucher summary, account code, debit / credit direction, and transaction amount, comprehensively meeting the user's business needs for display and secondary filtering.

[0070] like Figure 3 As shown, a second aspect of the present invention provides an intelligent accounting data retrieval and analysis system combining AI, comprising: The index building unit is used to obtain the accounting voucher set, jointly encode the summary, account code, debit / credit direction and transaction amount of each voucher, generate voucher embedding vector that integrates account semantics and debit / credit semantics, classify vouchers into permission-related partitions according to the multi-level permission hierarchy tree from accounting entity to detailed account, generate partition boundary embedding vectors that identify the account level for each partition, and use this index to index the voucher embedding vectors of the corresponding partitions to build an account permission semantic index library. The authorization identifier unit is used to receive accounting retrieval queries, generate query embedding vectors through semantic parsing, parse user identity credentials to determine authorized account hierarchical nodes, trace from this node along the multi-level permission hierarchy tree to the root node of the accounting entity, collect the account permission boundary identifiers of the higher-level nodes along the way, and form a set of account authorization identifiers. The permission retrieval unit is used to locate the authorized subject partition that matches the subject authorization identifier set in the subject permission semantic index library, using the subject authorization identifier set as the access credential. The query embedding vector is then compared with the credential embedding vector within the authorized subject partition using cosine similarity retrieval to obtain a candidate result set for permission isolation. The sorting output unit is used to calculate the sorting score for each voucher in the candidate result set, using the cosine similarity between the voucher embedding vector and the query embedding vector as the first-level sorting factor and the hierarchical depth of the subject permission partition to which the voucher belongs as the second-level decay factor, and output the accounting voucher retrieval results in descending order.

[0071] Figure 3 This is a schematic diagram of the structure of an AI-powered intelligent accounting data retrieval and analysis system. The system interface intuitively demonstrates the entire process of intelligent accounting data retrieval. The top features an entry point for natural language retrieval and role switching; the left side presents a multi-level permission topology tree, dynamically highlighting the authorization boundary tracing link from the current role to the root node, achieving visualized permission control; the right side displays accounting data matched based on a distributed semantic index, and annotates a comprehensive score that integrates semantic similarity and hierarchical decay factors, clearly presenting the technical logic that balances data security and accurate ranking.

[0072] like Figure 4 As shown, Figure 4 This diagram illustrates a multi-level permission hierarchy tree topology, showcasing the current set of authorization boundary identifiers (tracing path) of this invention. The system parses the identity credential and extends unidirectionally from the authorization level towards the root node, forming an ordered chain of permission boundary identifiers. This identity credential can only retrieve authorized partition data that matches this set.

[0073] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0074] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0075] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

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

Claims

1. A method for intelligent retrieval and analysis of accounting data combining AI, characterized in that: include: Obtain the accounting voucher set, and jointly encode the summary, account code, debit / credit direction and transaction amount of each voucher. Generate a voucher embedding vector that integrates account semantics and debit / credit semantics. According to the multi-level permission hierarchy tree from accounting entity to detailed account, classify the vouchers into permission ownership partitions according to the account permission boundaries. Generate partition boundary embedding vectors that identify the account level for each partition. Use this to index the voucher embedding vectors of the corresponding partitions and build an account permission semantic index library. The system receives accounting retrieval queries, performs semantic parsing to generate query embedding vectors, parses user identity credentials to determine authorized account hierarchical nodes, traces from these nodes along a multi-level permission hierarchy tree to the root node of the accounting entity, collects account permission boundary identifiers passed through higher-level nodes, and forms a set of account authorization identifiers. Using the set of subject authorization identifiers as access credentials, the authorized subject partition that matches the set of subject authorization identifiers is located in the subject permission semantic index library. The query embedding vector and the credential embedding vector within the authorized subject partition are then subjected to cosine similarity retrieval to obtain a set of candidate results for permission isolation. For each voucher in the candidate result set, the cosine similarity between the voucher embedding vector and the query embedding vector is used as the first-level ranking factor, and the hierarchical depth of the subject permission partition to which the voucher belongs is used as the second-level decay factor. The ranking score is calculated in a comprehensive manner and the accounting voucher retrieval results are output in descending order.

2. The method according to claim 1, characterized in that, The voucher is divided into permission-related partitions based on the permission boundaries of the subject, and a partition boundary embedding vector is generated for each partition to construct a subject permission semantic index library, including: For all the voucher embedding vectors within the permission-attributed partition, extract the accounting subject permission subtree topology corresponding to the partition in the multi-level permission hierarchy tree. The accounting subject permission subtree topology includes the subject hierarchy depth of each subject node in the subtree rooted at the subject node corresponding to the partition, the unique code identifier of the parent subject node, the sub-sub ... The accounting subject permission subtree topology is encoded into a fixed-length subject permission topology feature vector by the subject tree topology encoder, and the subject permission topology feature vector is used as the partition boundary embedding vector of the partition. A one-to-many index mapping table is established between the partition boundary embedding vector and the physical storage address of each voucher embedding vector within the corresponding partition. Each partition is arranged in a progressive order from shallow to deep according to the subject level depth of the subject node corresponding to its partition boundary embedding vector in the multi-level permission hierarchy tree, thus constructing a subject hierarchy index tree structure. Each non-leaf node in the subject hierarchy index tree stores the value range of the partition boundary embedding vector corresponding to all sub-partitions covered by the subject permission subtree rooted at it. Each leaf node stores the physical storage address of all voucher embedding vectors within the corresponding partition, thereby forming the subject permission semantic index library.

3. The method according to claim 1, characterized in that, Parse user identity credentials to determine the authorized account level node, and trace along the multi-level permission hierarchy tree from that node to the root node of the accounting entity to collect account permission boundary identifiers, forming a set of account authorization identifiers, including: The user role label carried by the user identity credential is matched layer by layer with the set of accounting job roles associated with each subject node in the multi-level permission hierarchy tree. The matching starts from the root node of the accounting entity in the multi-level permission hierarchy tree and is traversed from top to bottom through each subject level. For each subject node in the current traversal level, query the set of accounting job roles attached to the subject node, determine whether the user role tag belongs to the set of accounting job roles, and determine the subject node that first determines the membership relationship from the root node as the user's authorized subject level node. The subject corresponding to the authorized subject level node and all its subordinate sub-sub ... Starting from the authorized subject level node, traverse upwards along the parent pointer link of the multi-level permission hierarchy tree to the root node of the accounting entity, collecting the subject permission boundary identifiers associated with each authorized subject level node and each parent subject node along the way. Arrange the subject permission boundary identifiers of the authorized subject level node at the head of the chain, and then arrange the subject permission boundary identifiers of each parent subject node in the order of traversal from near to far, forming a unidirectional ordered chain of subject permission boundary identifiers extending from the authorized subject level to the root node of the accounting entity. Use this identifier chain as the set of subject authorization identifiers.

4. The method according to claim 3, characterized in that, Tracing from this node along the multi-level permission hierarchy tree to the root node of the accounting entity includes: In each jump step along the parent pointer link, the subject permission boundary identifier of the current subject node is extracted as the sub-subject identifier, and the subject permission boundary identifier of the parent subject node is extracted as the parent subject identifier. The sub-subject identifier and the parent subject identifier form a subject permission inclusion relationship pair to be verified. A matching query is performed in the subject permission inclusion relationship table that is pre-constructed offline according to the complete subject parent-child relationship of the multi-level permission hierarchy tree. Sequentially register the one-to-one direct inclusion mapping of subject permissions between the parent subject node permission boundary identifier and the permission boundary identifier of each direct child subject node on each parent-child subject connection edge. Store it in a key-value pair mapping structure, where the key is the parent subject identifier and the value is the set of all direct child subject identifiers under the parent subject. Only when there is a mapping record in the subject permission inclusion relationship table that registers the sub-subject identifier as a member of the direct sub-subject set of the parent subject identifier, will the subject permission boundary identifier of the parent subject node be included in the subject permission boundary identifier chain. This is to prevent nodes without a valid subject parent-child relationship from gaining unauthorized access to the upper-level subject level voucher data by forging subject attribution relationships.

5. The method according to claim 1, characterized in that, In the subject permission semantic index, locate the partition boundary embedding vector that matches the authorized subject partition of the authorized identifier set, and perform cosine similarity retrieval between the query embedding vector and the voucher embedding vector within the authorized subject partition to obtain a candidate result set, including: The cosine similarity value between the subject permission boundary identifier and the partition boundary embedding vector of the subject partition is calculated respectively. This is used as a similarity metric to measure whether the subject partition belongs to the subject permission jurisdiction identified by the subject permission boundary identifier in the subject permission hierarchy semantic space. For each subject permission boundary identifier, subject partitions whose cosine similarity value exceeds the preset subject partition matching threshold are selected to form a subset of matching subject partitions that uniquely corresponds to the subject permission boundary identifier. The union of the subsets of matching subject partitions corresponding to each of the subject permission boundary identifiers is obtained. All the voucher records covered by each subject partition in the union constitute the complete set of voucher data that the user can legally retrieve according to his / her subject permissions. This union is used as the authorized subject partition. Based on the physical storage address, read all the voucher embedding vectors stored in the authorized subject partition one by one. Calculate the cosine similarity between each read voucher embedding vector and the query embedding vector. Sort the voucher embedding vectors in descending order of cosine similarity from high to low. Extract the candidate voucher records that are in the first preset number of sorted positions to form the candidate result set.

6. The method according to claim 1, characterized in that, The ranking score is calculated by combining the cosine similarity between the voucher embedding vector and the query embedding vector as the primary ranking factor and the hierarchical depth of the account permission partition to which the voucher belongs as the secondary decay factor. The accounting voucher retrieval results are then output in descending order, including: The first-level ranking factor is the normalized accounting document semantic similarity value after the cosine similarity between the document embedding vector corresponding to each candidate document and the query embedding vector is processed by minimum-maximum normalization. This normalization process linearly maps the original cosine similarity values ​​between different query batches to the same preset numerical range to eliminate the difference in the distribution of absolute values ​​of semantic relevance between batches. The secondary attenuation factor is the ratio of the total number of subject levels in the multi-level permission hierarchy tree to the subject level depth of the current candidate voucher's subject permission partition in the multi-level permission hierarchy tree; The comprehensive ranking score is the product of the normalized accounting voucher semantic similarity value and the secondary decay factor. This ensures that candidate vouchers whose summary semantic content is highly relevant to the query and whose subject level is relatively shallow in the multi-level permission hierarchy tree receive a higher final ranking score than candidate vouchers with similar semantic content relevance but whose subject level is relatively deep. Based on the comprehensive ranking score of each candidate voucher, they are sorted in descending order to generate a ranked sequence of accounting voucher retrieval results, which is then output.

7. An AI-integrated intelligent accounting data retrieval and analysis system, used to implement the method as described in any one of claims 1-6, characterized in that, include: The index building unit is used to obtain the accounting voucher set, jointly encode the summary, account code, debit / credit direction and transaction amount of each voucher, generate voucher embedding vector that integrates account semantics and debit / credit semantics, classify vouchers into permission-related partitions according to the multi-level permission hierarchy tree from accounting entity to detailed account, generate partition boundary embedding vectors that identify the account level for each partition, and use this index to index the voucher embedding vectors of the corresponding partitions to build an account permission semantic index library. The authorization identifier unit is used to receive accounting retrieval queries, generate query embedding vectors through semantic parsing, parse user identity credentials to determine authorized account hierarchical nodes, trace from this node along the multi-level permission hierarchy tree to the root node of the accounting entity, collect the account permission boundary identifiers of the higher-level nodes along the way, and form a set of account authorization identifiers. The permission retrieval unit is used to locate the authorized subject partition that matches the subject authorization identifier set in the subject permission semantic index library, using the subject authorization identifier set as the access credential. The query embedding vector is then compared with the credential embedding vector within the authorized subject partition using cosine similarity retrieval to obtain a candidate result set for permission isolation. The sorting output unit is used to calculate the sorting score for each voucher in the candidate result set, using the cosine similarity between the voucher embedding vector and the query embedding vector as the first-level sorting factor and the hierarchical depth of the subject permission partition to which the voucher belongs as the second-level decay factor, and output the accounting voucher retrieval results in descending order.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images