Enterprise intelligent knowledge retrieval system driven by multi-source heterogeneous data
Patent Information
- Application Number
- CN202611161670.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-03
- Publication Date
- 2026-10-27
AI Technical Summary
但其局限性在于:知识图谱构建仅依赖原始数据源ID与生成时间,未针对文档与API数据开展语义化处理;权限模型为角色-组织-数据粒度的粗粒度控制,未实现段落级的内容级细粒度权限管控;溯源机制仅能标识数据源类别,不支持点击跳转至原始数据的溯源验证功能
1、本发明首创文档-数据库-API三类异构数据的统一语义表示框架,将三类异构数据统一映射至同一语义空间,解决了现有技术仅能覆盖单一数据源的问题,真正打破企业知识的数据孤岛。
Smart Images

Figure CN122985984A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of artificial intelligence, natural language processing, knowledge graphs, enterprise information systems, and data retrieval technologies. Specifically, it relates to an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data. Background Technology
[0002] With the continuous advancement of enterprise digital transformation, current enterprise knowledge base retrieval technologies mainly include the following types of technical solutions: The first type is the traditional keyword retrieval scheme, which is usually based on search engines such as Elasticsearch and Solr. It performs word segmentation on documents and builds an inverted index. After the user enters keywords, it returns a list of documents containing the corresponding keywords. Its technical limitation is that it only supports literal text matching and cannot understand the semantic meaning of the user's query.
[0003] The second category comprises intelligent retrieval solutions that integrate knowledge graphs and semantic vectors. For example, Chinese patent application CN202512004863.7 encodes document summaries and text segments into summary vectors and text segment vectors, respectively, and stores them in a vector database. Simultaneously, it constructs a knowledge graph to store the relationships between concept phrases and text segments. However, this solution only covers document-based data sources and does not integrate database or API interface data; the retrieval results lack a source tracing mechanism; and it does not involve enterprise-level access control and audit trail capabilities.
[0004] The third category is enterprise multi-source knowledge tracing solutions with enhanced retrieval capabilities. For example, the Chinese patent application with publication number CN202511835485.0 retrieves knowledge fragments using a standardized knowledge graph, generates natural language responses using a large language model, and dynamically controls the granularity of the responses based on a three-dimensional permission model. However, its limitations are: the knowledge graph construction relies solely on the original data source ID and generation time, without semantic processing for document and API data; the permission model is a coarse-grained control at the role-organization-data granularity level, failing to achieve fine-grained permission control at the paragraph level and content level; and the tracing mechanism can only identify the data source category and does not support the function of clicking to jump to the original data for tracing verification.
[0005] The fourth category consists of existing RAG-enhanced retrieval schemes, which add a re-ranking step to vector retrieval. However, this type of scheme still has significant shortcomings: it typically only covers a single data source; it lacks an effective source tracing mechanism after generating the answer; and it has weak reasoning ability regarding relationships between business entities.
[0006] In summary, existing enterprise knowledge base retrieval technologies generally suffer from the following technical shortcomings: First, the problem of data silos from multiple sources is prominent. Enterprise knowledge is scattered across three types of heterogeneous data sources: documents, databases, and APIs. Existing solutions can only cover one type of data and cannot achieve unified semantic representation and joint retrieval of the three types of heterogeneous data.
[0007] Second, there are inherent limitations in retrieval accuracy. Pure vector retrieval has a weak ability to understand the semantics of structured data, while pure keyword retrieval has a low recall rate for unstructured documents. Neither can simultaneously address the retrieval performance of different types of data.
[0008] Third, the generation of answers lacks traceability. After generating answers, large models cannot clearly inform users of the data source for the conclusions, failing to meet the requirement that all conclusions in enterprise auditing and compliance management be verifiable.
[0009] Fourth, it lacks enterprise-level application support features. Existing search solutions do not fully consider the essential features required in enterprise scenarios, such as hierarchical access control, data timeliness management, and end-to-end audit tracing. The cost of implementation and adaptation is high, making it difficult to directly meet the requirements of enterprise-level production deployment.
[0010] No effective solutions have yet been proposed to address the problems in the relevant technologies. Summary of the Invention
[0011] To address the problems in related technologies, this invention proposes an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data, in order to overcome the aforementioned technical problems existing in existing related technologies.
[0012] Therefore, the specific technical solution adopted by the present invention is as follows: A multi-source heterogeneous data-driven enterprise-level intelligent knowledge retrieval system, comprising: The query parsing and intent recognition module is used to classify intent, recognize entities, and rewrite queries based on the user's natural language query, and output query intent data. The multi-source heterogeneous data representation module is used to perform differentiated semantic processing on multi-source heterogeneous data and build semantic indexes. The hybrid reasoning retrieval module is used to perform retrieval in the semantic index based on the query intent data, and sequentially perform graph reasoning, vector retrieval and cross-source aggregation on the retrieval results, and output a sorted sequence of fact fragments; The answer generation and citation module is used to take each fact fragment in the sorted sequence of fact fragments and the associated data source location identifier as context input to the large language model to generate a natural language answer containing citation source tags; The permissions and auditing module is used to perform hierarchical permission verification and content security filtering throughout the entire retrieval process, and to record the complete retrieval behavior in an unalterable manner. The permissions and auditing module establishes bidirectional data connections with the query parsing and intent recognition module, the multi-source heterogeneous data representation module, the hybrid reasoning retrieval module, and the answer generation and tracing module, respectively, and performs permission verification and auditing records throughout the entire retrieval process.
[0013] Preferably, the query parsing and intent recognition module includes: The intent classification submodule is used to identify the intent type corresponding to the user's natural language query and output the intent classification result. The entity recognition submodule is used to extract key entities and constraints from user natural language queries and output entity recognition results. The query rewriting submodule is used to rewrite queries based on intent classification results and entity recognition results, and output query intent data.
[0014] Preferably, the multi-source heterogeneous data representation module includes: The document semanticization submodule is used to segment document-type data sources, perform semantic vector encoding and entity relation extraction on each text block, bind metadata to each text block, and generate a document-type semantic index. The database semantics submodule is used to obtain table structure, field annotations and foreign key relationships based on relational databases, extract representative sample data to generate data summaries, preserve query language links, and generate database-like semantic indexes. The API semantics submodule is used to extract interface paths, request parameters, return fields and function descriptions, perform semantic vector encoding on the interface function descriptions, establish a mapping relationship between interface parameters and business entities, and generate API class semantic indexes. The semantic index includes document-type semantic index, database-type semantic index, and API-type semantic index.
[0015] Preferably, the hybrid reasoning retrieval module includes: The graph reasoning submodule is used to perform entity localization and graph traversal in the semantic index based on the query intent data to obtain the target entity and the associated path. The vector retrieval submodule is used to narrow the retrieval scope based on the target entity and the associated relationship path, and to perform semantic vector retrieval of multi-source heterogeneous data within the narrowed retrieval scope, and output multi-source candidate fact fragments; The cross-source aggregation submodule is used to perform comprehensive sorting, deduplication and merging, and conflict detection on candidate fact fragments from multiple sources in sequence, and output the sorted sequence of fact fragments.
[0016] Preferably, entity location and graph traversal are performed in the semantic index based on the query intent data to obtain the target entity and its associated path, including: Based on the list of target entities in the query intent data, the starting entity node is obtained by matching and locating it in the semantic index graph through the node label index. Starting from the initial entity node, perform a breadth-first graph traversal according to the preset traversal depth to obtain candidate associated entity nodes, corresponding association relationships, and traversal paths from the initial entity node to each candidate associated entity node. The confidence scores of candidate associated entity nodes and traversal paths are calculated based on path length and association strength. The target entity and association path are then output based on the confidence scores.
[0017] Preferably, the process of obtaining the target entity and its associated path by performing entity localization and graph traversal in the semantic index based on the query intent data further includes: When performing a query based on the data correspondence reasoning type, the shortest path of association between the starting entity node and the target entity node is calculated based on the breadth-first graph traversal, and the shortest path of association is used as the basis for calculating the confidence score.
[0018] Preferably, the search scope is narrowed based on the target entity and the associated relationship path, and semantic vector retrieval of multi-source heterogeneous data is performed within the narrowed search scope to output multi-source candidate fact fragments, including: Based on the target entity and the associated relationship path, determine the associated nodes and associated range of each target entity in the semantic index to obtain a narrowed search scope; Within the narrowed search scope, similarity matching is performed on the semantic vectors corresponding to various types of multi-source heterogeneous data, and various heterogeneous data fragments are retrieved. The various heterogeneous data fragments recalled are bound to the corresponding data source location identifiers and entity association information, and after format normalization, multi-source candidate fact fragments are output.
[0019] Preferably, within the narrowed search scope, similarity matching is performed on the semantic vectors corresponding to various types of multi-source heterogeneous data, and various heterogeneous data fragments are retrieved, including: Within a narrowed search scope, semantic vector similarity matching is performed on document-type data sources to recall document blocks that are semantically related to the query intent. Within the narrowed search scope, semantic vector similarity matching is performed on database-type data sources, and query statements are generated and recalled based on query language links; Within the narrowed search scope, semantic vector similarity matching is performed on API-type data sources, and call parameters are generated and recalled based on the semantic vectors of interface functions.
[0020] Preferably, the answer generation and tracing module includes: The source identification binding submodule is used to match and bind the corresponding data source location identifier to each fact fragment in the sorted fact fragment sequence, and integrate them to form context information; The answer generation submodule is used to input contextual information into the large language model and generate natural language answers that include source tagging. The source verification submodule is used to establish a mapping relationship between the reference source marker and the data source location identifier, and supports jumping to the corresponding original data location based on the reference source marker.
[0021] Preferably, the permissions and auditing module includes: The access control submodule is used to perform data source level access verification and content level security filtering at each stage of the entire retrieval process based on user identity information and query intent data, and to intercept unauthorized retrieval requests. The timeliness management submodule is used to configure differentiated cache timeliness and refresh strategies for multi-source heterogeneous data with different permission levels and different update frequencies; The audit trail submodule is used to obtain complete search behavior data throughout the entire search chain and write it into an immutable audit log, and generate an audit report based on the audit log.
[0022] The beneficial effects of this invention are as follows: 1. This invention is the first to create a unified semantic representation framework for three types of heterogeneous data: documents, databases, and APIs. It maps these three types of heterogeneous data to the same semantic space, solving the problem that existing technologies can only cover a single data source and truly breaking down data silos in enterprise knowledge.
[0023] 2. This invention pioneers a three-layer hybrid retrieval process: graph reasoning and positioning, vector precise recall, and cross-source aggregation and deduplication. Compared with pure vector retrieval schemes, this invention has stronger reasoning capabilities for complex queries involving multi-hop relationships and business entity associations, and significantly improves retrieval accuracy.
[0024] 3. This invention pioneers a multi-source traceability and verification mechanism for answer generation. Each factual fragment used to generate the answer is bound to a refined data source location identifier, which realizes the complete traceability, reviewability and verification of the answer, meeting the rigid requirements of enterprises for audit compliance.
[0025] 4. This invention constructs a comprehensive enterprise-level management and control system. Regarding access control, it employs dual access control at the data source and content levels; regarding data timeliness management, it implements differentiated caching strategies for three types of data sources; regarding audit tracing, it ensures audit logs are tamper-proof and can generate audit reports periodically. The built-in enterprise-level features enable this invention to be directly deployed in real-world business scenarios with stringent data security and compliance requirements, such as finance, healthcare, and government, demonstrating promising prospects for industrial applications. Attached Figure Description
[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0027] Figure 1 This is a schematic diagram of an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to an embodiment of the present invention. Figure 2 This is an overall architecture diagram of an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to an embodiment of the present invention; Figure 3 This is a flowchart of a hybrid reasoning retrieval process in an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data, according to an embodiment of the present invention.
[0028] In the picture: 1. Query parsing and intent recognition module; 2. Multi-source heterogeneous data representation module; 3. Hybrid reasoning retrieval module; 4. Answer generation and source tracing module; 5. Permissions and auditing module. Detailed Implementation
[0029] To further illustrate the various embodiments, the present invention provides accompanying drawings, which are part of the disclosure of the present invention. These drawings are mainly used to illustrate the embodiments and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these drawings, those skilled in the art should be able to understand other possible implementation methods and the advantages of the present invention. The components in the drawings are not drawn to scale, and similar component symbols are generally used to represent similar components.
[0030] According to embodiments of the present invention, an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data is provided.
[0031] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments, such as... Figure 1-3 As shown, according to an embodiment of the present invention, an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data includes: The query parsing and intent recognition module 1 is used to classify intent, recognize entities, and rewrite queries based on the user's natural language query, and output query intent data. In a preferred embodiment, the query parsing and intent recognition module 1 includes: The intent classification submodule is used to identify the intent type corresponding to the user's natural language query and output the intent classification result. The entity recognition submodule is used to extract key entities and constraints from user natural language queries and output entity recognition results. The query rewriting submodule is used to rewrite queries based on intent classification results and entity recognition results, and output query intent data.
[0032] It needs to be explained that the system receives natural language queries from users and classifies the intent using a large language model. This large language model employs a domain-fine-tuned LLM based on the Transformer architecture, such as the Baichuan2-7B model, which is fine-tuned on internal enterprise documents. It has 32 layers, 4096 hidden dimensions, 32 attention heads, and a maximum sequence length of 4096.
[0033] The specific process of intent classification is as follows: First, the user query is input into the LLM encoder. The Tokenizer converts the query text into a token sequence, which is then processed through a 32-layer Transformer for self-attention calculation, yielding the final hidden state vector with a dimension of 4096. Then, the classification head outputs the probability distributions of four intent categories: fact-based queries (prioritizing databases and APIs when the probability is highest), concept-based queries (prioritizing document queries), relational reasoning queries (prioritizing knowledge graph queries), and comprehensive analysis queries (triggering full-source joint retrieval). The classification head consists of a linear layer with an input dimension of 4096 and an output dimension of 4, followed by a Softmax activation function. The classification loss function is cross-entropy loss, and the training data consists of labeled enterprise query samples.
[0034] The specific process of entity recognition is as follows: the BERT-CRF model is used to identify key entities (person names, organization names, product names, time, etc.) in the query. The BERT-CRF model uses bert-base-chinese pre-trained weights, 12 Transformer layers, 768 hidden dimensions, and the CRF layer outputs a BIO labeled sequence.
[0035] The specific process of the BERT-CRF model in identifying key entities in a query is as follows: First, the BERT model's tokenizer segments the user query into a sequence of tokens, which is then input into the BERT encoder to obtain a context representation vector (768 dimensions) for each token. Next, this vector sequence is input into a CRF (Conditional Random Field) layer. The CRF layer models the query using a transition matrix and an emission matrix, outputting BIO (B-starting, I-middle, O-non-entity) labels for each token. Finally, the Viterbi decoding algorithm is used to find the optimal label sequence, from which key entities such as names of people, organizations, products, and times are extracted. The BERT encoder is a 12-layer Transformer with a hidden dimension of 768.
[0036] The specific process of query rewriting is as follows: converting natural language into structured query intent, which includes a list of target entities, relational path hints, data type preferences, and time range constraints.
[0037] Multi-source heterogeneous data representation module 2 is used to perform differentiated semantic processing on multi-source heterogeneous data and build semantic indexes; In a preferred embodiment, the multi-source heterogeneous data representation module 2 includes: The document semanticization submodule is used to segment document-type data sources, perform semantic vector encoding and entity relation extraction on each text block, bind metadata to each text block, and generate a document-type semantic index. The database semantics submodule is used to obtain table structure, field annotations and foreign key relationships based on relational databases, extract representative sample data to generate data summaries, preserve query language links, and generate database-like semantic indexes. The API semantics submodule is used to extract interface paths, request parameters, return fields and function descriptions, perform semantic vector encoding on the interface function descriptions, establish a mapping relationship between interface parameters and business entities, and generate API class semantic indexes. The semantic index includes document-type semantic index, database-type semantic index, and API-type semantic index.
[0038] It should be explained that the document semantics submodule generates a document-class semantic index, in which the document is divided into blocks by paragraph / chapter, the block size is 512 characters, the overlap is 128 characters, and the document structure hierarchy is preserved.
[0039] The specific process of dual encoding is as follows: each text block generates a semantic vector through the Embedding model, and entity relation triples are extracted through NER and relation extraction. The Embedding model adopts text2vec-large-chinese, a 12-layer Transformer, a hidden dimension of 1024, and outputs a 768-dimensional semantic vector. The specific process of generating semantic vectors through the Embedding model is as follows: First, the text block is cleaned (special characters are removed, and the encoding is unified). The tokenizer of the text2vec-large-chinese model is used to convert the text into a token sequence. The maximum length of the token sequence is 512, and zeros are added if it is insufficient and truncated if it is excessive. Then, it is input into a 12-layer Transformer encoder with a hidden dimension of 1024 and 16 attention heads. The hidden state vector (1024-dimensional) at the last layer [CLS] position is taken, and then it is reduced in dimension by a linear projection layer (1024→768), outputting a 768-dimensional semantic vector. This vector is then stored in a vector database after L2 normalization.
[0040] The specific process of NER and relation extraction is as follows: Named entity recognition is performed using the BERT-BiLSTM-CRF model (using bert-wwm-ext pre-trained weights to output BIO labels). Then, PCNN (segmented convolutional neural network) based on an attention mechanism is used for relation classification. Relationship categories are predefined (20 business relationships such as include, belong to, located in, responsible for, and produce). Metadata binding: Each text block is accompanied by a document ID, page number, author, version, and permission tag (public / internal / confidential).
[0041] The specific process of using the BERT-BiLSTM-CRF model for named entity recognition is as follows: BERT-WWM-EXT (a pre-trained Chinese word masking model) is used as the encoder to output the context representation vector (768 dimensions) of each character. This vector is then input into a bidirectional LSTM layer with a hidden dimension of 256, totaling 512 dimensions for both forward and backward directions. Finally, the vector is input into a CRF layer for BIO sequence labeling to identify entities such as personal names, place names, organization names, and product names in the text.
[0042] The specific process of using PCNN (Piecewise Convolutional Neural Network) based on attention mechanism for relation classification is as follows: For a sentence containing two entities, the sentence is first divided into three segments according to the positions of the two entities (before entity 1, between entity 1 and entity 2, and after entity 2). Each segment is convolved separately, with a kernel window size of 3 and 230 filters. Then, segmented max pooling is used to extract features for each segment. Next, the attention mechanism is used to calculate the attention weights of the features of different segments. Finally, the weighted feature vector is input into a fully connected layer (Softmax activation), which outputs a predefined probability distribution of relation categories (20 types of business relationships such as contain, belong to, located in, responsible for, and produce).
[0043] The database semantics submodule generates a database-like semantic index. Table structure semantics requires reading `INFORMATION_SCHEMA` to obtain table comments, field comments, and foreign key relationships. Sample data summaries extract 20 representative samples from each table, determining representativeness through statistical features: numeric fields take records within the mean ± standard deviation range; text fields take records with the median length; and time fields take the 10 newest and 10 oldest records. SQL query chains are preserved, with each semantic unit bound to a corresponding table name, field name, and executable SQL template. The SQL template uses a parameterized form, such as `SELECT {field} FROM {table name} WHERE {condition field} = ?`. Dynamic synchronization listens for change events through the database Binlog, automatically updating the semantic representation within 5 minutes of a change.
[0044] The specific process of reading INFORMATION_SCHEMA to obtain table comments, field comments, and foreign key relationships is as follows: In INFORMATION_SCHEMA (an information schema, a metadata database provided by relational databases such as MySQL), the names and comments of all tables in the database (TABLE_NAME, TABLE_COMMENT fields) are obtained by querying the TABLES table; the field names, field types, and field comments of each table (COLUMN_NAME, DATA_TYPE, COLUMN_COMMENT fields) are obtained by querying the COLUMNS table; and the foreign key relationships between tables (CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME fields) are obtained by querying the KEY_COLUMN_USAGE table.
[0045] Specific SQL query examples are as follows: SELECT TABLE_NAME, TABLE_COMMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'target database name'; SELECT COLUMN_NAME, DATA_TYPE, COLUMN_COMMENT FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'target database name' AND TABLE_NAME = 'target table name'; SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'target database name' ANDREFERENCED_TABLE_NAME IS NOT NULL.
[0046] The meanings of all the English letters mentioned in the text are supplemented as follows: INFORMATION_SCHEMA (Information schema, standard view of database metadata); BERT (Bidirectional Encoder Representations from Transformers); CRF (Conditional Random Field); NER (Named Entity Recognition); BiLSTM (Bidirectional Long Short-Term Memory); PCNN (Piecewise Convolutional Neural Network, used for relation extraction); LLM (Large Language Model); API (Application Programming Interface); SQL (Structured Query Language); Embedding (mapping discrete objects to continuous vectors); HNSW (Hierarchical Navigable Small World, an efficient approximate nearest neighbor search algorithm); BFS (Breadth First Search); WORM (Write Once Read Many); SLA (Service Level Agreement). Level Agreement (SA)); HTTP (Hypertext Transfer Protocol); RAG (Retrieval Enhancement Generation); Embedding (Encoding text into dense vectors).
[0047] The API semantics submodule generates a semantic index for API classes, which requires parsing OpenAPI / Swagger documentation, vectorizing API functions, and mapping call parameters. Parsing OpenAPI / Swagger documentation requires using the Swagger-Parser library to extract the API path, HTTP method, request parameters, return fields, and function description; API function vectorization requires encoding the API function description text into a 768-dimensional semantic vector using an embedding model; and call parameter mapping requires recording the mapping relationship between API input parameters and business entities, such as ` / orders / {orderId}` where `orderId` corresponds to the primary key of the business entity "order". The response caching strategy is designed differently for low-frequency and high-frequency change interfaces. Low-frequency change interfaces require static data interfaces to be cached for 24 hours; high-frequency change interfaces require real-time data interfaces to be either not cached or cached for only 5 minutes. The criteria for judgment are: if the change rate of the interface returned data in the past 7 days is <5%, it is low-frequency; >20% is high-frequency; and 5%-20% is medium-frequency and cached for 1 hour.
[0048] Swagger-Parser is an open-source library for parsing OpenAPI specification documents (Swagger documentation, in YAML or JSON format). The specific process of using Swagger-Parser to extract API paths, HTTP methods, request parameters, return fields, and feature descriptions is as follows: The `read()` method of the SwaggerParser class is called to load the OpenAPI documentation; the `paths` field of the documentation is traversed to obtain all API paths (e.g., ` / orders / {orderId}`); for each path, its HTTP method (GET / POST / PUT / DELETE) is read; the `parameters` field is read to obtain the request parameters (including parameter name, parameter type, whether required, parameter location, path / query / body, etc.); the `responses` field is read to obtain the structure and type of the returned fields; and the `summary` or `description` field is read to obtain the API feature description text.
[0049] The specific process of encoding the interface function description text into a 768-dimensional semantic vector using the Embedding model is as follows: The interface function description text is preprocessed, i.e., HTML tags are removed, case is standardized to lowercase, and extra spaces are removed; the text2vec-large-chinese model's tokenizer converts the text into a token sequence (maximum length 256); then, it is input into a 12-layer Transformer encoder to extract the 1024-dimensional vector at the [CLS] position; finally, it is reduced to 768 dimensions through a linear projection layer and L2 normalized to obtain the interface function semantic vector. This vector is used for subsequent matching of query intent with interface function.
[0050] Hybrid reasoning retrieval module 3 is used to perform retrieval in the semantic index based on the query intent data, and sequentially perform graph reasoning, vector retrieval and cross-source aggregation on the retrieval results, and output a sorted sequence of fact fragments; In a preferred embodiment, the hybrid reasoning retrieval module 3 includes: The graph reasoning submodule is used to perform entity localization and graph traversal in the semantic index based on the query intent data to obtain the target entity and the associated path. As a preferred implementation, entity localization and graph traversal are performed in the semantic index based on the query intent data to obtain the target entity and its associated path, including: Based on the list of target entities in the query intent data, the starting entity node is obtained by matching and locating it in the semantic index graph through the node label index. Starting from the initial entity node, perform a breadth-first graph traversal according to the preset traversal depth to obtain candidate associated entity nodes, corresponding association relationships, and traversal paths from the initial entity node to each candidate associated entity node. The confidence scores of candidate associated entity nodes and traversal paths are calculated based on path length and association strength. The target entity and association path are then output based on the confidence scores.
[0051] As a preferred implementation, the method of obtaining the target entity and its associated path by performing entity localization and graph traversal in the semantic index based on the query intent data further includes: When performing a query based on the data correspondence reasoning type, the shortest path of association between the starting entity node and the target entity node is calculated based on the breadth-first graph traversal, and the shortest path of association is used as the basis for calculating the confidence score.
[0052] The vector retrieval submodule is used to narrow the retrieval scope based on the target entity and the associated relationship path, and to perform semantic vector retrieval of multi-source heterogeneous data within the narrowed retrieval scope, and output multi-source candidate fact fragments; As a preferred implementation, the search scope is narrowed based on the target entity and the associated relationship path, and semantic vector retrieval of multi-source heterogeneous data is performed within the narrowed search scope to output multi-source candidate fact fragments, including: Based on the target entity and the associated relationship path, determine the associated nodes and associated range of each target entity in the semantic index to obtain a narrowed search scope; Within the narrowed search scope, similarity matching is performed on the semantic vectors corresponding to various types of multi-source heterogeneous data, and various heterogeneous data fragments are retrieved. The various heterogeneous data fragments recalled are bound to the corresponding data source location identifiers and entity association information, and after format normalization, multi-source candidate fact fragments are output.
[0053] As a preferred implementation, within the narrowed search scope, similarity matching is performed on the semantic vectors corresponding to various types of multi-source heterogeneous data, and various heterogeneous data fragments are retrieved, including: Within a narrowed search scope, semantic vector similarity matching is performed on document-type data sources to recall document blocks that are semantically related to the query intent. Within the narrowed search scope, perform semantic vector similarity matching on database-type data sources, and generate and recall query statements based on the query language link; Within the narrowed search scope, perform semantic vector similarity matching on API-type data sources, and generate and recall invocation parameters based on the interface function semantic vector.
[0054] A cross-source aggregation submodule, configured to sequentially perform comprehensive sorting, deduplication merging and conflict detection on multi-source candidate fact snippets, and output a sorted fact snippet sequence.
[0055] It should be noted that in the knowledge graph reasoning submodule, the entity in the user query needs to be located in the business entity relationship graph, and the graph is stored using the Neo4j graph database. The graph traversal algorithm first quickly locates the starting entity node through the node label index; then performs BFS (Breadth-First Search) traversal with a maximum depth of 3 layers and a maximum number of branches of 10 per layer; for relationship reasoning type queries, the shortest path algorithm (Dijkstra) is used to calculate the shortest relationship path between two entities. A related entity set, relationship paths, and confidence scores are output, wherein the shorter the path length and the higher the relationship weight, the higher the confidence.
[0056] The specific process of BFS (Breadth-First Search) traversal is: starting from the starting entity node, first access all direct neighbor nodes of this node (the 1st layer), then sequentially access the unvisited neighbors of each neighbor node (the 2nd layer), and so on, until the maximum depth of 3 layers is reached or all reachable nodes are traversed. In each layer, at most 10 branches with the highest confidence are retained. BFS is implemented using a queue data structure, with a time complexity of O(V+E), where V is the number of nodes and E is the number of edges.
[0057] The specific calculation process of the shortest path algorithm (Dijkstra) is: assume that each edge in the graph has a weight (representing relationship strength, with a value ranging from 0 to 1). The Dijkstra algorithm starts from the starting entity node s, and maintains a distance array dist[], where initially dist[s]=0, and dist[v]=∞ for all other nodes. In each step, the algorithm selects the undetermined node u with the current minimum distance, and for each neighbor v of u, performs a relaxation operation: if dist[u]+w(u,v)<dist[v], update dist[v]=dist[u]+w(u,v). The above process is repeated until the distance of the target node t is determined, and the shortest path length is dist[t]. The formula is expressed as: dist[v]=min(dist[v],dist[u]+w(u,v)); where w(u,v) represents the edge weight from node u to node v. Confidence score=1 / (1+dist[t])×average edge weight of the path.
[0058] The vector retrieval submodule needs to narrow down the candidate range of vector retrieval based on the entity set located in the graph. Document vector Top-K recall: Within the narrowed candidate set, the HNSW algorithm is used for approximate nearest neighbor search to recall the top-10 most similar document blocks. Dynamic generation of database SQL requires matching the query semantics with the semantic vectors of table fields; fields with a matching degree > 0.7 are used as query conditions, and executable SQL is automatically generated, such as `SELECT * FROM orders WHERE customer_name LIKE '%{entity}%'`. API parameter matching requires matching the query intent with the interface function vector; interfaces with a matching degree > 0.8 are used as candidates, and calling parameters are automatically generated.
[0059] The specific process of using the HNSW algorithm for approximate nearest neighbor search is as follows: HNSW constructs a multi-layer graph structure, with layer 0 containing all data points, and the number of points in each upward layer decreasing exponentially (decreasing with probability). The search starts from the highest layer, using a greedy algorithm to find the nearest entry point, and then proceeds layer by layer down to layer 0, searching for the nearest neighbor node to the query vector in each layer. A fine-grained search is performed at layer 0, returning the top-K nearest document blocks. The time complexity is O(logN), far superior to the O(N) of brute-force search.
[0060] The specific calculation process for matching query semantics with table field semantic vectors is as follows: The cosine similarity is calculated between the semantic vector (768 dimensions) of the user query and the semantic vectors of all table fields in the database, cos_sim(query,field)=(query·field) / (||query||×||field||), where · represents the vector dot product and ||·|| represents the L2 norm. The calculation results are sorted, and fields with a similarity > 0.7 are used as query conditions. SQL condition clauses are automatically generated based on the field type. Text-type fields are matched using LIKE, numeric fields using = or range matching, and time-type fields using BETWEEN.
[0061] The specific calculation process for matching query intent with interface function vectors is as follows: the user query is encoded into a 768-dimensional query semantic vector through the Embedding model, and the cosine similarity is calculated with each of the encoded interface function semantic vectors. Interfaces with a similarity > 0.8 are selected as candidates. Then, the interface path parameters are automatically filled in according to the entity parameters in the query (such as filling the order number in the query into / orders / {orderId}) to generate a complete API call request.
[0062] In the cross-source aggregation submodule, semantic relevance ranking requires calculating the semantic similarity between the search results and the query for each of the three types of search results. Specifically, document blocks use vector cosine similarity, database results use SQL query matching, and API results use functional vector similarity. Semantic similarity is then ranked by weighted scores: document weight 0.4, database weight 0.35, and API weight 0.25. For deduplication and merging, when the same fact exists in both documents and the database, the database result is prioritized (database data is more structured and more accurate). Conflict detection requires that when different source data contradict each other (e.g., a product price of 100 yuan in a document, 120 yuan in the database), a credibility score is calculated (database credibility > document credibility), the conflict is marked, and manual review is prompted.
[0063] The specific calculation process of using vector cosine similarity for document blocks is as follows: For each recalled document block, calculate the cosine similarity between its semantic vector and the query semantic vector, score_doc=cos_sim(query_vector,doc_vector)=(query_vector·doc_vector) / (||query_vector||×||doc_vector||), with a score range of [-1,1], which is normalized and mapped to the interval [0,1].
[0064] The specific calculation process for the database result matching score using SQL queries is as follows: For automatically generated SQL queries, the relevance between the query conditions and the user's requirements is calculated as follows: score_db = (number of matched fields / total number of query fields) × 0.5 + (number of returned result rows / expected number of result rows) × 0.5. If the returned result is empty, score_db = 0. The expected number of result rows is determined based on historical query statistics (the average number of rows returned by similar queries in the last 30 days). If there is no historical data, it is set to 10 by default.
[0065] The specific calculation process for API results using function vector similarity is as follows: score_api=cos_sim(query_vector,api_function_vector), which is the cosine similarity between the query semantic vector and the interface function semantic vector.
[0066] When data from different sources contradicts each other, the specific process for calculating the credibility score is as follows: A base credibility weight is set for each data source (W_db=0.5 in the database, W_doc=0.3 in the document, and W_api=0.2 in the API). The credibility score = base weight × data timeliness factor (newer is higher) × data source quality factor (historical accuracy). When the same fact is inconsistent across different sources, the credibility scores of each source are compared, and the result with the highest credibility is taken as the answer. Conflict information is then marked and manually reviewed.
[0067] The answer generation and tracing module 4 is used to take each fact fragment in the sorted fact fragment sequence and the associated data source location identifier as context input to the large language model to generate a natural language answer containing citation source tags; As a preferred implementation, the answer generation and tracing module 4 includes: The source identification binding submodule is used to match and bind the corresponding data source location identifier to each fact fragment in the sorted fact fragment sequence, and integrate them to form context information; The answer generation submodule is used to input contextual information into the large language model and generate natural language answers that include source tagging. The source verification submodule is used to establish a mapping relationship between the reference source marker and the data source location identifier, and supports jumping to the corresponding original data location based on the reference source marker.
[0068] It should be explained that each fact fragment used to generate the answer in the source identification binding submodule is accompanied by a source tag. The document source includes the document ID, page number, and paragraph number (format: DOC-{ID}@P{page number}#Para{paragraph}); the database source includes the table name, fields, record ID, and SQL statement (format: DB-{table name}@REC-{record ID}#SQL-{SQL hash}); and the API source includes the interface path, call time, and parameters (format: API-{path}@Time-{timestamp}#Param-{parameter hash}).
[0069] The answer generation submodule uses a large language model, ChatGLM3-6B, with 28 Transformer layers and 4096 hidden dimensions. It mandates that the answer include a source identifier, and the output format is "answer content [source 1: type + location information][source 2: type + location information]...".
[0070] The specific process of generating answers using a large language model is as follows: First, the retrieved multi-source fact fragments are sorted according to semantic relevance, and the top-5 most relevant fragments are selected as context. Then, a prompt template is constructed, with the format: "Answer the question based on the following references. References: [Fragment 1 source identifier + content][Fragment 2...] Question: {User query} Requirement: Citify the source in the answer, in the format [source number]." The prompt is input into the ChatGLM3-6B model (28-layer Transformer, 4096 hidden dimensions, maximum generated length 2048), and answers are generated token by token using an autoregressive approach. The generated answers are post-processed to ensure that all citation formats are correct and to filter out content that cannot be traced back to its source.
[0071] In the source tracing and verification submodule, users can directly jump to the original data by clicking the source tracing icon. Document source: Opens the corresponding document and highlights the corresponding paragraphs; Database source: Executes the corresponding SQL and displays the query results table; API source: Displays the interface call logs and the returned JSON data.
[0072] The permissions and audit module 5 is used to perform hierarchical permission verification and content security filtering throughout the entire retrieval process, and to record the complete retrieval behavior in an unalterable manner. Among them, the permission and audit module 5 establishes bidirectional data connections with the query parsing and intent recognition module 1, the multi-source heterogeneous data representation module 2, the hybrid reasoning retrieval module 3, and the answer generation and tracing module 4, respectively, and performs permission verification and audit records during the entire retrieval process.
[0073] As a preferred implementation, the permissions and auditing module 5 includes: The access control submodule is used to perform data source level access verification and content level security filtering at each stage of the entire retrieval process based on user identity information and query intent data, and to intercept unauthorized retrieval requests. The timeliness management submodule is used to configure differentiated cache timeliness and refresh strategies for multi-source heterogeneous data with different permission levels and different update frequencies; The audit trail submodule is used to obtain complete search behavior data throughout the entire search chain and write it into an immutable audit log, and generate an audit report based on the audit log.
[0074] It should be explained that in the access control submodule, data source level permissions are assigned according to user roles, which define the scope of accessible data sources. For example, ordinary employees can access documents and some database tables, while management can access all data sources. Content level permissions mean that different paragraphs in the same document may have different security levels, and they are filtered by paragraph permission tags, which are divided into four levels: public, internal, confidential, and top secret. Query interception means that when an unauthorized query is made, the system will return "You do not have permission to access this type of data" and record an audit log.
[0075] The mapping between user roles and data source scopes is as follows: Administrators have access to all data sources; Department Managers have access to their department's documents, database tables, and all APIs; Regular Employees have access to public documents, some database views, and authorized APIs; Visitors have access only to public documents. The permission scopes of the four roles progress in order, with Visitors… ordinary employees Department Manager administrator.
[0076] Access permissions are categorized into four levels: Public, Internal, Confidential, and Top Secret. Public level: Contains no sensitive information and can be displayed to all users (including visitors), such as company introductions and publicly available product information. Internal level: Contains internal operational information, accessible only to internal employees, such as internal process documents and non-sensitive business data. Confidential level: Contains trade secrets or sensitive customer information, accessible only to authorized personnel, such as contract details, financial data, and customer personal information. Top Secret level: Involves core trade secrets or information strictly protected by law, accessible only to a very small number of senior managers and specific authorized personnel, such as merger and acquisition plans and unpublished intellectual property documents. The classification is based on a comprehensive consideration of three dimensions: information sensitivity, legal compliance requirements, and scope of business impact.
[0077] During the document semantic markup process, permission markers (such as [Confidential]) at the beginning of paragraphs are matched using regular expressions, or sensitive content is automatically identified and marked with permission levels based on LLM. The specific process for setting paragraph permissions is as follows: The specific process of regular expression matching is as follows: During document parsing, regular expression matching is performed on the beginning of each paragraph. The matching pattern is: ^\s*\[(Public|Internal|Confidential|Top Secret)\]\s*. If the beginning of a paragraph contains the tags [Public], [Internal], [Confidential], or [Top Secret], then the paragraph is marked with the corresponding permission level. This method is suitable for scenarios where the document author has explicitly marked permission tags in the content.
[0078] The specific process of automatic identification based on LLM is as follows: For paragraphs without manually marked permission tags, a large language model is used for automatic sensitive content identification and permission labeling. Specifically, the paragraph text is input into a finely tuned BERT classification model (4 categories: Public / Internal / Confidential / Top Secret). The model automatically determines the permission level of the paragraph based on sensitive keywords (such as passwords, amounts, contracts, etc.), entity types (person names, organization names, amounts, ID numbers, etc.) and contextual semantics. The model training data consists of manually labeled enterprise document paragraph samples, the loss function is cross-entropy loss, and the accuracy is >92%.
[0079] In the timeliness management submodule, database data is queried in real time without caching or with a short cache (5 minutes); API data is cached according to the interface configuration caching strategy, static data is cached for 24 hours, and dynamic data is cached in real time; document data version management prioritizes returning the latest version when searching, and historical versions can be switched.
[0080] The audit trail submodule must fully record the queryer, query time, query content, data source of the retrieval, retrieval results, and generated answers; logs are written to WORM storage and cannot be tampered with; audit reports are generated regularly to statistically analyze high-frequency queries, abnormal queries, and data usage frequency.
[0081] like Figure 2 The diagram shows the overall architecture of an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data. Specifically, the overall system architecture flow is as follows: user query layer → query parsing and intent recognition module → unified semantic layer for multi-source heterogeneous data (document semantics / database semantics / API semantics) → hybrid index management layer (vector index, graph index, and structured index) → graph-vector hybrid reasoning retrieval module → answer generation and multi-source tracing module → enterprise-level permissions and auditing module → answer output layer (with tracing identifier). Figure 3 The diagram shown is a flowchart of the hybrid reasoning retrieval process.
[0082] The following section provides a detailed explanation of an enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data, using specific application scenarios as examples.
[0083] Taking financial risk control scenarios as an example, financial risk control scenarios require unified querying across three types of data sources: documents (such as risk control reports), databases (such as transaction record tables), and APIs (such as credit reporting interfaces). Through full module collaboration, a retrieval accuracy rate of over 92% and an average response time of less than 2 seconds can be achieved.
[0084] Taking medical literature retrieval as an example, the medical literature retrieval scenario requires cross-source retrieval of a large number of medical literature, clinical trial databases and drug information APIs and understanding of professional terms. Through query parsing and intent recognition modules to understand professional medical terms, multi-source heterogeneous data representation modules to integrate multi-source data, and hybrid reasoning retrieval modules to perform accurate recall, an entity recognition accuracy rate of over 95% can be achieved.
[0085] Taking enterprise compliance audit scenario as an example, each audit conclusion must be accompanied by traceable data source and the audit trace must be tamper-proof. By binding data source location identifiers to each fact fragment through the answer generation and traceability module, and recording the complete retrieval behavior and writing it into WORM storage through the permission and audit module, 100% traceability coverage is achieved.
[0086] Taking the intelligent customer service system scenario as an example, the intelligent customer service system scenario needs to respond to user inquiries in real time and dynamically obtain real-time data from the business system. It understands user questions through query parsing and intent recognition modules, obtains dynamic data by calling business interfaces in real time through the API semanticization sub-module, and quickly generates replies through the answer generation and tracing module, achieving an API call latency of less than 500 milliseconds.
[0087] Taking the R&D knowledge management scenario as an example, the R&D knowledge management scenario needs to perform unified retrieval of scattered technical documents, R&D database tables and internal APIs and implement hierarchical permission control. Through the document semanticization submodule to perform block retrieval of technical documents, the database semanticization submodule to associate with R&D database tables, and the permission control submodule to implement hierarchical permission management, a document retrieval recall rate of over 90% can be achieved.
[0088] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. An enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data, characterized in that: The system includes: The query parsing and intent recognition module is used to classify intent, recognize entities, and rewrite queries based on the user's natural language query, and output query intent data. The multi-source heterogeneous data representation module is used to perform differentiated semantic processing on multi-source heterogeneous data and build semantic indexes. The hybrid reasoning retrieval module is used to perform retrieval in the semantic index based on the query intent data, and sequentially perform graph reasoning, vector retrieval and cross-source aggregation on the retrieval results, and output a sorted sequence of fact fragments; The answer generation and citation module is used to take each fact fragment in the sorted sequence of fact fragments and the associated data source location identifier as context input to the large language model to generate a natural language answer containing citation source tags; The permissions and auditing module is used to perform hierarchical permission verification and content security filtering throughout the entire retrieval process, and to record the complete retrieval behavior in an unalterable manner. The permissions and auditing module establishes bidirectional data connections with the query parsing and intent recognition module, the multi-source heterogeneous data representation module, the hybrid reasoning retrieval module, and the answer generation and tracing module, respectively, and performs permission verification and auditing records throughout the entire retrieval process.
2. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 1, characterized in that, The query parsing and intent recognition module includes: The intent classification submodule is used to identify the intent type corresponding to the user's natural language query and output the intent classification result. The entity recognition submodule is used to extract key entities and constraints from user natural language queries and output entity recognition results. The query rewriting submodule is used to rewrite queries based on intent classification results and entity recognition results, and output query intent data.
3. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 1, characterized in that, The multi-source heterogeneous data representation module includes: The document semanticization submodule is used to segment document-type data sources, perform semantic vector encoding and entity relation extraction on each text block, bind metadata to each text block, and generate a document-type semantic index. The database semantics submodule is used to obtain table structure, field annotations and foreign key relationships based on relational databases, extract representative sample data to generate data summaries, preserve query language links, and generate database-like semantic indexes. The API semantics submodule is used to extract interface paths, request parameters, return fields and function descriptions, perform semantic vector encoding on the interface function descriptions, establish a mapping relationship between interface parameters and business entities, and generate API class semantic indexes. The semantic index includes document-type semantic index, database-type semantic index, and API-type semantic index.
4. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 3, characterized in that, The hybrid reasoning retrieval module includes: The graph reasoning submodule is used to perform entity localization and graph traversal in the semantic index based on the query intent data to obtain the target entity and the associated path. The vector retrieval submodule is used to narrow the retrieval scope based on the target entity and the associated relationship path, and to perform semantic vector retrieval of multi-source heterogeneous data within the narrowed retrieval scope, and output multi-source candidate fact fragments; The cross-source aggregation submodule is used to perform comprehensive sorting, deduplication and merging, and conflict detection on candidate fact fragments from multiple sources in sequence, and output the sorted sequence of fact fragments.
5. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 4, characterized in that, The step of performing entity localization and graph traversal in the semantic index based on query intent data to obtain the target entity and its associated path includes: Based on the list of target entities in the query intent data, the starting entity node is obtained by matching and locating it in the semantic index graph through the node label index. Starting from the initial entity node, perform a breadth-first graph traversal according to the preset traversal depth to obtain candidate associated entity nodes, corresponding association relationships, and traversal paths from the initial entity node to each candidate associated entity node. The confidence scores of candidate associated entity nodes and traversal paths are calculated based on path length and association strength. The target entity and association path are then output based on the confidence scores.
6. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 5, characterized in that, The step of performing entity localization and graph traversal in the semantic index based on query intent data to obtain the target entity and its associated path also includes: When performing a query based on the data correspondence reasoning type, the shortest path of association between the starting entity node and the target entity node is calculated based on the breadth-first graph traversal, and the shortest path of association is used as the basis for calculating the confidence score.
7. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 4, characterized in that, The process involves narrowing the search scope based on the target entity and its associated relationship path, and then performing semantic vector retrieval of multi-source heterogeneous data within the narrowed search scope. The output of multi-source candidate fact fragments includes: Based on the target entity and the associated relationship path, determine the associated nodes and associated range of each target entity in the semantic index to obtain a narrowed search scope; Within the narrowed search scope, similarity matching is performed on the semantic vectors corresponding to various types of multi-source heterogeneous data, and various heterogeneous data fragments are retrieved. The various heterogeneous data fragments recalled are bound to the corresponding data source location identifiers and entity association information, and after format normalization, multi-source candidate fact fragments are output.
8. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 7, characterized in that, Within the narrowed search scope, similarity matching is performed on the semantic vectors corresponding to various types of multi-source heterogeneous data, and various heterogeneous data fragments are retrieved, including: Within a narrowed search scope, semantic vector similarity matching is performed on document-type data sources to recall document blocks that are semantically related to the query intent. Within the narrowed search scope, semantic vector similarity matching is performed on database-type data sources, and query statements are generated and recalled based on query language links; Within the narrowed search scope, semantic vector similarity matching is performed on API-type data sources, and call parameters are generated and recalled based on the semantic vectors of interface functions.
9. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 1, characterized in that, The answer generation and tracing module includes: The source identification binding submodule is used to match and bind the corresponding data source location identifier to each fact fragment in the sorted fact fragment sequence, and integrate them to form context information; The answer generation submodule is used to input contextual information into the large language model and generate natural language answers that include source tagging. The source verification submodule is used to establish a mapping relationship between the reference source marker and the data source location identifier, and supports jumping to the corresponding original data location based on the reference source marker.
10. The enterprise-level intelligent knowledge retrieval system driven by multi-source heterogeneous data according to claim 1, characterized in that, The permissions and auditing module includes: The access control submodule is used to perform data source level access verification and content level security filtering at each stage of the entire retrieval process based on user identity information and query intent data, and to intercept unauthorized retrieval requests. The timeliness management submodule is used to configure differentiated cache timeliness and refresh strategies for multi-source heterogeneous data with different permission levels and different update frequencies; The audit trail submodule is used to obtain complete search behavior data throughout the entire search chain and write it into an immutable audit log, and generate an audit report based on the audit log.
Citation Information
Patent Citations
Method, device and equipment for retrieving and enhancing enterprise multi-source knowledge traceability and storage medium
CN121256067A
Intelligent retrieval method and system fusing knowledge graph and semantic vector
CN122019765A