A modular knowledge graph and retrieval-enhanced large model fusion and interaction method and system for financial branches

Abstract

This application discloses a modular knowledge graph and retrieval-enhanced large-scale model fusion and interaction method and system for financial branches. The method includes: obtaining a query vector for a target object, wherein the query vector includes a question vector expressing the target object's query needs and a job vector reflecting the target object's job information within the financial branch; determining the policy modules accessible to the target object based on the job vector; identifying the subgraph region corresponding to the question vector in the knowledge graph; retrieving the document paragraph corresponding to the subgraph region from the sub-index library corresponding to the policy module; and inputting the document paragraph into the large-scale model to generate the target answer corresponding to the query vector. This application solves the technical problem of related question-answering systems lacking recognition of user job identities and failing to provide matching answers based on different job responsibilities and permissions within financial branches.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically, to a modular knowledge graph and retrieval-enhanced large model fusion and interaction method and system for financial branches. Background Technology

[0002] Currently, the application of large pre-trained language models in financial branches faces a series of challenges, especially in building intelligent question-answering, knowledge search, and semantic retrieval systems, where their performance and functionality are limited in many ways. For example, the question-answering systems used in these technologies lack the ability to identify the user's job title, cannot provide matching answers based on the different job responsibilities and permissions within the financial branch, and struggle to ensure compliance with regulations, leading to the risk of illusion in answers generated under complex institutional frameworks.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a modular knowledge graph and retrieval-enhanced large model fusion and interaction method and system for financial branches, which at least solves the technical problem that the question-answering system used in related technologies lacks the ability to identify the user's job position and cannot provide matching answers according to the different job responsibilities and permissions of financial branches.

[0005] According to one aspect of the embodiments of this application, a method for fusing and interacting modular knowledge graphs and retrieval-enhanced large-scale models for financial branches is provided, comprising: obtaining a query vector of a target object, wherein the query vector includes a question vector for expressing the query needs of the target object and a job vector for reflecting the job information of the target object in the financial branch; determining the policy modules accessible to the target object based on the job vectors, wherein the policy modules are units that logically divide policy documents according to the business domains of the financial branch; determining a subgraph region corresponding to the question vector in the knowledge graph, wherein the knowledge graph is used to represent the logical structure between policy documents; retrieving document paragraphs corresponding to the subgraph region in the sub-index library corresponding to the policy module, and inputting the document paragraphs into the large-scale model to generate a target answer corresponding to the query vector.

[0006] In some embodiments of this application, determining the system modules accessible to the target object based on the job vector includes: obtaining multi-dimensional tags corresponding to all system modules, wherein the multi-dimensional tags include business domain tags for limiting the scope of application of the system documents, line attribute tags for refining the business lines under the business domain, and job applicability tags for restricting access permissions; determining the similarity between the job vector and the multi-dimensional tags, and comparing the job permission information in the job vector with the job applicability tags to obtain a comparison result; determining the system modules accessible to the target object based on the similarity and the comparison result, wherein each system module corresponds to a sub-index library, and the sub-index library is used to store the system documents corresponding to the system module.

[0007] In some embodiments of this application, the knowledge graph is constructed by: extracting entities from a set of policy documents, wherein the entities include policy clauses; determining the relationships between entities, and determining the edges of the knowledge graph based on the relationships, wherein the relationships include one of the following: reference relationships, application relationships, inheritance relationships, and substitution relationships between policy clauses; and constructing the knowledge graph based on the entities and edges.

[0008] In some embodiments of this application, determining the subgraph region corresponding to the question vector in the knowledge graph includes: matching the question vector with the knowledge graph to obtain a first graph node, wherein the first graph node includes nodes whose similarity to the semantic features of the question vector is greater than or equal to a first preset threshold; searching the graph path starting from the first graph node based on the edges of the knowledge graph, stopping the search when a stopping condition is met, and obtaining a second graph node set, wherein the stopping condition includes the similarity between the semantic features of the second graph node and the question vector being less than a second preset threshold, and the second preset threshold being less than a first preset threshold; and determining the subgraph region based on the first graph node and the second graph set.

[0009] In some embodiments of this application, inputting a document paragraph into a large model to generate a target answer corresponding to a query vector includes: obtaining guidance information from the large model, wherein the guidance information includes path information of the document paragraph in the knowledge graph and job information of the target object, the path information being used to indicate the institutional logic and structural order followed by the large model when generating the answer; constructing a target template based on the guidance information, wherein the target template includes control instructions corresponding to the path information and constraints corresponding to the job information; and processing the control instructions and constraints using the large model to obtain the target answer.

[0010] In some embodiments of this application, after retrieving the document paragraph corresponding to the subgraph region in the sub-index library corresponding to the system module, the method further includes: obtaining the metadata tags corresponding to the child nodes of the subgraph region, wherein the metadata tags include the effective date, repeal date, and applicable region of the system document; when there are multiple versions of the system document corresponding to the child node, determining the matching score between the system document corresponding to each version and the query vector based on the metadata tags, wherein the matching score is used to quantify the applicability of the document paragraph corresponding to each version; and determining the target document paragraph for generating the target answer based on the matching score.

[0011] In some embodiments of this application, determining the matching score between the policy document corresponding to each version and the query vector based on metadata tags includes: obtaining the query time corresponding to the query vector, and determining a first indicator based on the query time, the effective time and the repeal time of the version, wherein the first indicator is used to quantify the timeliness of the version; obtaining the query region corresponding to the query vector, and determining a second indicator based on the query region and the applicable region of the version, wherein the second indicator is used to quantify the regional conformity of the version; determining a third indicator between the question vector in the query vector and the policy document of the version, wherein the third indicator includes semantic similarity; and determining the matching score based on the first indicator, the second indicator and the third indicator.

[0012] According to another aspect of the embodiments of this application, a modular knowledge graph and retrieval-enhanced large-scale model fusion interactive system for financial branches is also provided, including an interactive device and a server. The interactive device, connected to the server, is used to obtain a query vector of a target object, wherein the query vector includes a question vector describing the target object's query needs and a job vector reflecting the target object's job information within the financial branch. The server, connected to the interactive device, is used to determine the policy modules accessible to the target object based on the job vectors, wherein the policy modules are units that logically divide policy documents according to the business domains of the financial branch. A subgraph region corresponding to the question vector is determined in the knowledge graph, wherein the knowledge graph is used to represent the logical structure between policy documents. Document paragraphs corresponding to the subgraph regions are retrieved from the sub-index library corresponding to the policy modules, and the document paragraphs are input into the large-scale model to generate a target answer corresponding to the query vector.

[0013] According to another aspect of the embodiments of this application, a modular knowledge graph and retrieval-enhanced large model fusion interaction device for financial branches is also provided, comprising: an acquisition module for acquiring a query vector of a target object, wherein the query vector includes a question vector for expressing the query needs of the target object and a job vector for reflecting the job information of the target object in the financial branch; a determination module for determining the policy modules accessible to the target object based on the job vector, wherein the policy modules are units that logically divide policy documents according to the business domain of the financial branch; a matching module for determining the subgraph region corresponding to the question vector in the knowledge graph, wherein the knowledge graph is used to represent the logical structure between policy documents; and an interaction module for retrieving document paragraphs corresponding to the subgraph region in the sub-index library corresponding to the policy module, and inputting the document paragraphs into the large model to generate a target answer corresponding to the query vector.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the above-described modular knowledge graph and retrieval-enhanced large model fusion interaction method for financial branches.

[0015] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned modular knowledge graph and retrieval-enhanced large model fusion interaction method for financial branches by running the computer program.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches.

[0017] In this embodiment, a method integrating job information and query requirements is adopted. By generating a query vector containing question vectors and job vectors, the system modules that match the target job are selected. The subgraph region corresponding to the question vector is located in the knowledge graph. Then, a refined document paragraph retrieval is performed in the sub-index library corresponding to the selected system module. These paragraphs are then used as context input into the large model to generate answers. This achieves the goal of accurately matching user queries with accessible system modules and precisely defining the logical boundaries of semantic retrieval. As a result, the technical effects of generating enhanced question-and-answer content with job suitability and system compliance are achieved, and the efficiency of retrieval and the accuracy of answers are improved. This solves the technical problem that the question-and-answer system used in related technologies lacks the ability to identify the user's job identity and cannot provide matching answers based on the different job responsibilities and permissions of financial branches. Attached Figure Description

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

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal for a modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches, according to an embodiment of this application.

[0020] Figure 2 This is a flowchart of a modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches, according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the structure of a modular knowledge graph and retrieval enhanced large model fusion and interaction device for financial branches, according to an embodiment of this application. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0025] Large Language Model (LLM): Also known as a large model, it is a type of ultra-large-scale pre-trained language model built on deep learning techniques, especially the Transformer architecture. It aims to capture language patterns from massive amounts of text data through unsupervised learning, thereby possessing advanced natural language processing capabilities such as semantic understanding, text generation, and dialogue interaction. In this embodiment, the LLM serves as the core generation engine, responsible for generating high-quality, personalized answers that meet user needs and identity background after receiving specific question vectors and job title vectors.

[0026] Retrieval-Augmented Generation (RAG) is a question-answering system architecture that combines information retrieval technology with a pre-trained generative model. RAG first uses semantic similarity to retrieve document fragments related to the question from a knowledge base, then inputs these fragments as auxiliary context into the generative model to generate answers based on actual document support. In this embodiment, the RAG mechanism is optimized to support job awareness and multi-level knowledge module retrieval, improving the accuracy and reliability of the question-answering results.

[0027] Traditional intelligent question-answering systems and large models lack a deep understanding and dynamic perception of user roles and identities. As a result, when generating answers, the system fails to consider the specific position of the questioner (such as risk control personnel, legal affairs specialists, or retail banking business personnel), as well as the different access permissions, understanding, and expression methods of these positions for knowledge content. Such systems often provide a generalized answer that does not take into account role differences. This not only reduces the user experience, but may also lead to business errors because the answer exceeds the user's authority or does not meet their specific needs.

[0028] Furthermore, while current semantic retrieval systems based on vector matching can understand the intent of a question to some extent, they fall short when faced with complex and ever-changing financial knowledge systems. For example, these systems typically store all document fragments in a unified vector library for global similarity matching, ignoring the departmental attributes, scope of application, and version control of policy documents. This can lead to the erroneous recall of policy content from different business departments, outdated policies, or policies that are not applicable to the current position, which may be pieced together into the answer, resulting in problems such as "mixed use of knowledge modules" and "incorrect policy citations."

[0029] Furthermore, the financial industry has strict audit and traceability requirements for the output of intelligent question-and-answer systems. However, most current question-and-answer systems lack a clear link between their answers and the original policy documents, and cannot provide the specific policy provisions, versions, and sources on which the answers are based. This makes it impossible to effectively audit and verify the answers when disputes arise, and it is also not conducive to compliance checks and accountability. This greatly limits the application of intelligent question-and-answer systems in the core business processes of financial institutions.

[0030] To address the aforementioned technical problems, this application provides corresponding solutions, which are detailed below.

[0031] The modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing a modular knowledge graph and retrieval-enhanced large model fusion interaction method for financial branches is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0032] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0033] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the modular knowledge graph and retrieval-enhanced large model fusion interaction method for financial branches in this embodiment of the application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned modular knowledge graph and retrieval-enhanced large model fusion interaction method for financial branches. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0034] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0035] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0036] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0037] Under the above operating environment, this application provides an embodiment of a modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0038] Figure 2 This is a flowchart illustrating a modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches, according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0039] Step S202: Obtain the query vector of the target object, wherein the query vector includes a question vector that describes the query needs of the target object and a job vector that reflects the job information of the target object in the financial branch.

[0040] In step S202 above, the query vector refers to the transformation of the query requirement for the target object into a computer-processable vector form. In some embodiments of this application, the query vector may consist of a question vector and a job vector, used to guide the retrieval system and model to more accurately understand and respond to user queries.

[0041] (1) Question Vector: A mathematical vector representation of the specific query requirements of the target object. For example, it can be generated by a semantic encoding model based on the natural language question input by the user. The role of the question vector is to provide semantic input for the retrieval stage and help the system understand the user's intent and context. In some embodiments of this application, when generating the question vector, the natural language question input by the user can be converted into a vector representation by a semantic encoding model. The semantic encoding model can be a deep learning model based on the Transformer architecture, such as BERT or its variants. In specific implementation, the question can be input into the encoder part of the model. The vector output by the model will capture the key semantic features of the question. For example, if the user's query is "What are the latest policies for loans to micro and small enterprises?", the semantic encoding model will generate a vector that not only contains the semantic information of loans and policies, but also implicitly contains the two key conditions of micro and small enterprises and latest.

[0042] (2) Job Vector: A mathematical vector reflecting the job status and authority of the target object in a financial branch. It can also be generated by a specialized model based on the user's job information. The role of the job vector is to limit the institutional boundaries of the retrieval and generation process, ensuring that the answer content conforms to the user's job authority and business scope. The construction of the job vector involves converting multi-dimensional information such as the target object's organizational attributes, job responsibilities, and knowledge authority into a vector representation. In some embodiments of this application, a vector space can be designed, where each dimension represents a job feature, such as business area, department, or level of responsibility, and a vector is defined for each job. The value of each dimension reflects the attribute of the job in the corresponding feature. For example, for "risk compliance position", its vector has a high value in the "compliance" dimension and a high value in the "risk management" dimension, but may be zero or close to zero in the "product sales" dimension. This vector is used to filter and customize the response content during the retrieval and generation stage to ensure that the answer conforms to the job authority and responsibility requirements.

[0043] When user queries involve complex contexts, to ensure that question vectors accurately reflect the user's true intent and contextual information, and to prevent the inclusion of irrelevant or semantically biased content in search results, the semantic representation of question vectors can be further enhanced by leveraging contextual information such as the user's historical query records, operational behaviors, and business scenarios during the question vector generation process. For example, if the user is a client manager who frequently handles loan business, and this query is made while approving a specific loan project, the system can convert this historical behavior and current scenario information into vectors and integrate them with the question vectors to enhance the job-specific context and business background representation of the question vectors.

[0044] Step S204: Determine the system modules accessible to the target object based on the job vector. The system module is a unit that logically divides system documents according to the business areas of the financial branch.

[0045] In step S204 above, the policy module is a set of documents logically divided according to the business areas and / or job responsibilities and / or policy types of the financial branch. Each policy module revolves around a specific business area or responsibility function and contains a set of related policy documents and operating guidelines. The purpose of the policy module is to provide a structured way of organizing knowledge, making it easier for the system and users to locate specific business rules and operating procedures, thereby achieving accurate knowledge retrieval and effective utilization.

[0046] In some embodiments of this application, a multi-dimensional job tag mapping method can be used to determine the system modules. Specifically, when determining the system modules that the target object can access, the system first parses the multi-dimensional job tag information carried in the job vector, including but not limited to job name, department, business line, knowledge permission level, etc. Then, it maps this information to a predefined system module access control list. This list records in detail the access permissions of each job to different system modules. For example, for the "risk compliance" tag in the job vector, the system will query the system modules associated with risk compliance in the control list, such as "credit risk management" and "fund flow monitoring policy", thereby determining the scope of content that the target user can access.

[0047] In addition to using job tags for direct permission mapping, this application can also introduce a knowledge graph-based system module permission management mechanism. The knowledge graph can not only express the logical relationships between system documents, but also embed job access rules and the scope of application of the system. Specifically, the system locates the user's (i.e., the target object's) role node in the graph based on the job vector, and identifies the accessible paths under that node through a graph traversal algorithm. This identifies the set of system modules the user can query. For example, the "Risk and Compliance Position" node may have access to specific modules under the graph such as "Internal Control Processes" and "Compliance Reports." The system automatically identifies these paths and restricts the search scope to ensure that the answer content aligns with the user's permissions.

[0048] The above steps address the problem that existing question-and-answer systems cannot provide customized answers for users with different job positions and permissions. By combining job position vectors with access rules for the policy module, the system can limit the scope of retrieval and answer generation based on the user's specific job position and knowledge permissions, avoiding cross-departmental information leakage or access to unauthorized policy content, and ensuring the compliance and security of financial knowledge services.

[0049] When a user has multiple roles or cross-departmental responsibilities, in order to determine their comprehensive access permissions and avoid permission conflicts or omissions, the following steps can be performed: The system maintains a cross-position permission system, which records the rules for permission inheritance and merging between different positions. For example, a "risk compliance specialist" may have access permissions to both the "credit" and "fund flow monitoring" modules, while a "senior risk compliance specialist" may inherit the former's permissions and also gain access to the "cross-border risk assessment" module. When processing such position vectors, the system will automatically merge all relevant permissions of the user according to this permission system to form a comprehensive access permission list.

[0050] It should be noted that when a user has complex or variable roles, the system can employ a dynamic permission resolution algorithm to calculate the set of policy modules they can access in real time. Specifically, this algorithm, based on the identity information in the job vector, automatically analyzes permission inheritance paths and cross-permission scopes using a knowledge graph structure that embeds job access rules and policy application scopes. This ensures that access decisions for each module are based on the user's current full range of roles and permissions. For example, if a user is simultaneously a "Retail Banking Manager" and an "Internal Control and Compliance Consultant," the system will resolve the permissions for these two roles separately and then merge them to determine a comprehensive list of policy modules that can be accessed.

[0051] When a user's identity changes dynamically or when operations are performed across departments, the system also has a role context awareness function, which can automatically identify the user's current task scenario and temporary role, and dynamically adjust their access permissions. For example, when a "retail banking customer manager" is performing a specific "fund flow monitoring and investigation" task, the system can temporarily enhance their access permissions to the "fund flow monitoring" module to ensure that they can obtain all the policy information required to perform the task.

[0052] In some embodiments of this application, the system modules accessible to the target object can be determined through the following steps: obtaining multi-dimensional tags corresponding to all system modules, wherein the multi-dimensional tags include business domain tags for limiting the scope of application of system documents, line attribute tags for refining business lines under the business domain, and job applicability tags for restricting access permissions; determining the similarity between job vectors and multi-dimensional tags, and comparing the job permission information in the job vectors with the job applicability tags to obtain comparison results; determining the system modules accessible to the target object based on the similarity and comparison results, wherein each system module corresponds to a sub-index library, and the sub-index library is used to store the system documents corresponding to the system module.

[0053] Specifically, multidimensional tags can include business area tags, line attribute tags, and job applicability tags, used to accurately describe the scope of application, subdivided business areas, and access permissions of the policy documents, among which:

[0054] (1) Business area tag: used to identify the main business scope covered by the policy document, such as "retail banking", "corporate banking", "compliance and supervision", "risk management", etc. This tag helps the system understand the macro business area of ​​the document.

[0055] (2) Business line attribute tags: Further refinement based on business area tags, involving specific business lines or operating procedures, such as "personal loans", "credit cards", "fund flow monitoring", "credit review", etc., to distinguish the meso-level business attributes of the system documents.

[0056] The determination of line attribute tags can be based on business domain tags, combined with the specific content of policy documents, business processes, and organizational structure. The following examples illustrate this. Suppose there is a collection of policy documents with the business domain "Retail Banking," and we want to further refine the document classification within this domain to support more precise retrieval and access control. The specific steps are as follows:

[0057] 1) Analyze the content of institutional documents: Perform semantic analysis and text mining on all institutional documents in the "retail banking" field to identify key processes, products and services that frequently appear in the documents. For example, identify frequently mentioned business lines such as "personal loan approval", "credit card issuance" and "savings account management" from the "retail banking" institutional documents.

[0058] 2) Develop line attribute tags: Based on the identification results, develop a set of line attribute tags for the "retail banking" field, including but not limited to "personal loans", "credit cards", "savings accounts", "wealth management", etc. Each tag reflects the specific business line or operation process in the "retail banking" field, providing detailed standards for subsequent access control and document retrieval.

[0059] 3) Tagging documents with line attribute labels: For each policy document in the "Retail Banking" field, the corresponding line attribute label is applied according to the actual business lines it covers. For example, a policy document about "Personal Loan Approval Process" will be labeled with the "Personal Loan" line attribute label, while another document about "Credit Card Fraud Detection" will be labeled with both "Credit Card" and "Anti-Fraud".

[0060] 4) Maintain the mapping relationship between line attributes and business domains: Maintain a mapping table or relationship network in the system to record the association between each line attribute label and its corresponding business domain label. For example, the lines "personal loans", "credit cards", and "savings accounts" are all mapped to the business domain "retail banking", forming a hierarchical label system.

[0061] 5) Building Index Repositories and Retrieval Algorithms: Policy documents with line attribute tags are stored in different sub-index repositories, each corresponding to a specific business line. During actual retrieval, the system quickly locates the corresponding major category index repository based on the business domain tags in the user's query, and then further filters the document set based on the line attribute tags, thereby achieving accurate positioning and efficient retrieval.

[0062] (3) Job applicability tags: Define the access permissions and applicable objects of the documents, such as "all employees", "specific positions", "internal audit", "risk control department", etc., to ensure that only users with the corresponding permissions can access the corresponding documents, thus maintaining the security and compliant use of information.

[0063] In some embodiments of this application, the system first obtains the multidimensional tags of all policy modules and converts them into vector representations. Then, it calculates the similarity between the job vector and the multidimensional tag vectors of each policy module (e.g., using cosine similarity calculation). Based on the similarity score, it determines the policy modules that a user can access. Through vectorization and similarity calculation, the system can quickly and accurately determine the policy modules that a user can access based on their specific job position and permissions. This avoids the inefficiency and mismatch risks associated with traditional keyword- or rule-based permission management, and improves the accuracy and flexibility of permission control.

[0064] When determining which policy modules a target object can access, the system can also compare the job permission information in the job vector with the job applicability tags of the policy modules. If the comparison results show that the user's job and the applicability tags of the policy modules are matched, and the similarity calculation result is higher than the preset permission threshold, the system determines that the user can access the corresponding policy modules.

[0065] To facilitate understanding of the above process, some specific embodiments are explained below.

[0066] In a large commercial bank, suppose user A is a "senior manager in the credit department" whose work involves multiple business areas, including but not limited to "corporate loans", "personal consumer loans" and "risk management". User A needs to inquire about the specific details of the "corporate loan approval process".

[0067] Step 1: Obtain multidimensional labels.

[0068] The system first obtains multi-dimensional tag information for all policy modules within the bank, including but not limited to business area tags, line attribute tags, and job suitability tags. For example, the multi-dimensional tags for the "Corporate Loans" policy module might include: "Corporate Banking" (business area tag), "Corporate Loan Approval" (line attribute tag), and "Credit Department Manager and above" (job suitability tag). The multi-dimensional tags for the "Risk Management" policy module might include: "Risk Management" (business area tag), "Loan Risk Assessment" (line attribute tag), and "All Risk Management Department Staff" (job suitability tag).

[0069] Step 2: Calculate similarity and comparison permissions.

[0070] Similarity calculation: The system calculates the similarity between user A's job vector and the multi-dimensional label vector of each system module. For "Senior Manager of Credit Department", the weight of "corporate loan" and "risk management" in its job vector is relatively high. The system compares the job vector with the business area and line attribute label vector of each system module to obtain a series of similarity scores.

[0071] Permission Comparison: The system compares user A's job permission information (e.g., "Senior Manager of Credit Department") with the job applicability tags in the policy modules to check for a match. For the "Corporate Loans" and "Risk Management" policy modules, since "Senior Manager of Credit Department" falls under the scope of "Credit Department Manager and above" and "All Personnel of Risk Management Department," the comparison result is a match.

[0072] Step 3: Identify the accessible policy modules.

[0073] Based on the similarity score and permission comparison results in step 2, the system determines the policy modules that user A can access. In this example, the "Corporate Loans" and "Risk Management" policy modules have high similarity scores, and their job suitability tags match user A's job permission information. Therefore, the system identifies these two policy modules as targets that user A can access.

[0074] Step 4: Index location and document retrieval.

[0075] The system identifies the target policy modules and locates their corresponding sub-index libraries: the "Corporate Loan" policy module has its own sub-index library, and the "Risk Management" policy module has its own sub-index library. Within these sub-index libraries, the system can use semantic search technology to retrieve policy documents related to the "Corporate Loan Approval Process" based on the vector representation of user A's query requirements. Because the sub-index libraries have already undergone pre-screening by business line and access permissions, the search results will be more accurate and secure.

[0076] Step S206: Determine the subgraph region corresponding to the question vector in the knowledge graph, wherein the knowledge graph is used to represent the logical structure between institutional documents.

[0077] In step S206 above, a knowledge graph is a data structure used to represent the logical relationships and structural dependencies between financial institutional documents, such as entity relationships, institutional references, and business process chains. Its role is to provide a structured view of the institutional content, helping the system understand the internal connections of the institutional text, thereby making more reasonable and accurate decisions in the retrieval and generation stages.

[0078] A subgraph region is a local structure or set of nodes in a knowledge graph associated with a specific question vector. It is used to limit the focus of the intelligent question-answering system during the policy retrieval process, ensuring that the generated answer conforms to the semantic scope and specific context of the question. In some embodiments of this application, when a user asks a question, the system first maps the question vector to one or more semantic anchors in the knowledge graph. These semantic anchors can be nodes in the graph most relevant to the question topic; for example, "personal loan approval process" might point to the "personal loan" or "approval" node. Subsequently, the system can perform a multi-hop path search in the graph, exploring the set of nodes reached from the semantic anchors through logical edges such as "reference," "related," and "inheritance," forming a subgraph region that matches the question vector.

[0079] In the complex institutional structure of financial institutions, the above search strategy can help the system understand the deep semantics of questions, avoid erroneous recalls due to superficial semantic similarities, ensure that the generated answers are highly relevant to user needs, and follow the logical relationships between institutional documents, thereby improving the accuracy and compliance of question and answer.

[0080] It should be noted that the knowledge graph can also be logically partitioned according to business domains or job permissions. Each partition contains a set of nodes and edges directly related to that domain or permission. Once the business domain or job of the user query is determined, the system only performs multi-hop path search in the corresponding partition, instead of searching the entire graph, which further reduces the computational complexity of the search.

[0081] In determining subgraph regions, the system can also adjust the weights of nodes and edges in the graph based on the urgency and relevance of the user's query. For example, if the question is "What are the latest requirements for the policy on monitoring fund flows?", then nodes and edges directly related to "monitoring fund flows" (such as "policy announcements" and "latest revisions") will be assigned higher weights, while indirectly related or outdated nodes will have lower weights. The system sorts multi-hop paths according to their weights and prioritizes subgraph regions formed by paths with higher weights, thereby ensuring the timeliness and authority of the answers.

[0082] When constructing a multi-hop path search and weight adjustment mechanism for a knowledge graph, determining the direct and indirect relevance of nodes and edges is crucial to ensuring the timeliness and authority of the answers. In some embodiments of this application, the weights of individual nodes and edges can be adjusted based on the urgency and relevance of the user's query:

[0083] Step 1: Construct a Term Frequency-Inverse Document Frequency (TF-IDF) weighted model. First, perform text analysis on all nodes in the knowledge graph. For example, based on the topic "fund flow monitoring policy" (i.e., the query topic extracted from the question vector), calculate the TF-IDF value for each node. Directly related nodes (such as "policy announcement" and "latest revision") tend to mention the topic frequently in documents and are relatively unique in the graph, thus their TF-IDF values ​​are relatively high. Indirectly related nodes (such as "customer due diligence") are also related to the topic, but their mention frequency and uniqueness are lower, resulting in smaller TF-IDF values.

[0084] Step 2: Define the time weighting function. For example, for the keyword "latest requirements," the system needs to identify which nodes contain the most recently updated information. It should be noted that if the question vector does not contain time-related keywords, the question vector's creation date can be used as the benchmark. Specifically, a time weighting function can be defined. This function takes the node's update time or version release date as input and outputs a weight value to quantify the correlation between the node's time and the time indicated by the question vector. In the example above, newer information receives a higher weight value.

[0085] Step 3: Implement the graph traversal and weight accumulation algorithm.

[0086] a. Determining the starting point: Map the user's question vector to the knowledge graph and find the initial node most relevant to the question. In the example above, it could be the "funds flow monitoring policy" node.

[0087] b. Weight initialization: Assign initial weights to the starting node and all edges directly connected to it. Directly related edges (such as edges pointing to "Policy Announcement" and "Latest Revision") will receive higher initial weights, while indirectly related edges will have lower weights.

[0088] c. Multi-hop path weight update: Starting from the originating node, a multi-hop traversal is performed along all edges. During the traversal, the weights of each node and edge are dynamically adjusted based on their relevance to the query topic (TF-IDF value) and timeliness (output value of the time weight function). For example, the weight of a node is the product of the average weights reached through all its edges and the node's TF-IDF value, while the weight of an edge is a weighted average of the TF-IDF values ​​of its connected nodes and the result calculated by the time weight function.

[0089] d. Weight Propagation and Reduction: During graph traversal, weights gradually decrease with each hop to reduce the weight of indirectly related nodes, ensuring the system's focus remains on the nodes most directly relevant to the query. For example, an exponential decay function can be used, reducing the weight by 50% with each hop.

[0090] e. Subgraph region determination: After traversal, the system will sort all reachable nodes according to the comprehensive weight of the nodes (initial weight + TF-IDF value + time weight), and select the top N nodes with the highest weight to form the subgraph region. The size of N can be dynamically adjusted according to the system design and the complexity of the query.

[0091] Step 4: Prioritization and Response Generation: Based on the weights of nodes in the subgraph region, the system prioritizes nodes with higher weights as the basis for response generation, ensuring that the response content is based primarily on the latest and most relevant information. Simultaneously, nodes with higher weights will serve as the primary information source, while indirectly relevant or outdated nodes will only be used as supplementary information or background knowledge to enhance the completeness and depth of the response.

[0092] In some embodiments of this application, a knowledge graph can be constructed by: extracting entities from a set of policy documents, wherein the entities include policy clauses; determining the relationships between entities, and determining the edges of the knowledge graph based on the relationships, wherein the relationships include one of the following: reference relationships, application relationships, inheritance relationships, and substitution relationships between policy clauses; and constructing a knowledge graph based on the entities and edges.

[0093] Entities refer to key components extracted from various institutional documents, including but not limited to institutional clauses, policies and regulations, process steps, and job roles. Relationships are the relationships between entities, such as "reference," "application," "inheritance," and "substitution." They are crucial for constructing the logical structure of a knowledge graph, connecting entities to form the edges of the knowledge graph, reflecting the logical dependencies and evolutionary trajectories between institutional clauses, and helping the system understand the dynamic changes and semantic connections of institutions, including:

[0094] (1) Citation relationship: refers to a clause of a system directly citing another clause as its basis or reference. For example, the "loan approval process" cites the "customer due diligence requirements" as a necessary step before approval.

[0095] (2) Applicable relationship: indicates that an entity or clause applies to a specific position or business scenario, such as “loan approval process” applies to “credit department manager”.

[0096] (3) Inheritance relationship: describes the succession relationship between the old and new system clauses, meaning that the new clauses continue or modify the content of the old clauses to some extent. For example, the "2024 version of the loan approval process" is inherited from the "2023 version of the loan approval process".

[0097] (4) Substitution relationship: refers to a new clause replacing an old or outdated clause and becoming the new standard of implementation. For example, "the newly revised fund flow monitoring policy" replaces "the 2022 version of the fund flow monitoring policy".

[0098] After constructing a basic knowledge graph—that is, a graph structure containing institutional clauses and their referencing, application, inheritance, and substitution relationships—it is possible to further integrate job information and authority information from financial branches. Specifically:

[0099] (1) Introduce job nodes: Add "jobs" as new entity nodes to the knowledge graph, including but not limited to "teller", "account manager" and "risk compliance specialist". These job nodes will be listed alongside other entity nodes such as policy terms and process nodes to form part of the graph, representing specific business operators and information consumers.

[0100] (2) Define the applicable relationship: Establish an "applicable relationship" edge between the job node and the system clause. This relationship indicates which positions a certain system or process is specifically applicable to. For example, establish an applicable relationship between "Loan Approval Process" and "Credit Department Manager" to indicate that "Loan Approval Process" is specifically set for the "Credit Department Manager" position. In this way, the system can ensure that only system clauses that match the job authority are retrieved and used.

[0101] (3) Permission tags and edge weights: Add permission tags to each job node and policy clause node. These tags can include "readable", "editable", "requires review", etc. At the same time, add permission weights to the edges of the application relationship to indicate whether different jobs can access or apply the policy clause. Permission weights can be binary (accessible / inaccessible) or multi-level (such as read-only, editable, full control, etc.).

[0102] (4) Constructing a permission filtering mechanism: During the graph retrieval and answer generation process, the system needs to construct a permission filtering mechanism. First, based on the user's identity information, determine their job node and corresponding permission tags; when searching for policy clauses that match the question vector, the system only allows access to clause nodes that have a direct or indirect applicable relationship with the user's job node and whose permission weight allows it, so as to ensure that the generated answer content conforms to the user's access permissions and job responsibilities.

[0103] (5) Dynamic permission adjustment: Considering that job permissions may be adjusted over time, project or policy changes, the knowledge graph also has a dynamic permission adjustment mechanism. For example, by monitoring the update of job permissions through event listeners, once it is detected that the permissions of the "Credit Department Manager" job have changed (such as the addition of review rights), the applicable edge weights of the job in the graph will be automatically updated to ensure that the system can reflect the permission changes in a timely manner and avoid outdated permission control from affecting the accuracy of question and answer.

[0104] In some embodiments of this application, a subgraph region corresponding to a question vector can be determined in a knowledge graph in the following manner: matching the question vector with the knowledge graph to obtain a first graph node, wherein the first graph node includes nodes whose semantic feature similarity to the question vector is greater than or equal to a first preset threshold; searching the graph path starting from the first graph node based on the edges of the knowledge graph, stopping the search when a stopping condition is met, and obtaining a second graph node set, wherein the stopping condition includes the second graph node having a semantic feature similarity to the question vector that is less than a second preset threshold, and the second preset threshold being less than a first preset threshold; and determining a subgraph region based on the first graph node and the second graph set.

[0105] The first graph node is a candidate node in the knowledge graph whose semantic similarity to the question vector is greater than or equal to a first preset threshold. These nodes are considered highly relevant to the question and serve as a starting point for graph path searching. The second graph node set is the set of all nodes that meet the stopping condition when searching the graph path from the first graph node. This set is used to limit the subgraph range with a high degree of relevance to the user's question, ensuring that the search results do not deviate from the semantic core of the user's query. The subgraph region is a local area of ​​the knowledge graph related to the user's question, determined based on the first and second graph node sets.

[0106] Specifically, the first graph node can be analyzed to identify the edges it connects to and the nodes they point to. Based on the edge type (such as reference, application, inheritance, substitution relationship), the graph path can be expanded in multiple hops to explore nodes that are directly or indirectly related to the semantic features of the problem. During the graph path expansion process, the system sets a stopping condition, such as stopping the search when the similarity between the second graph node and the problem vector is lower than a second preset threshold. The search boundary is represented by the set of the second graph nodes.

[0107] In the institutional knowledge graph of financial branches, the type of edge not only reflects the complex logical relationships between entities, but also implies different strategies for retrieval and knowledge expansion. In some embodiments of this application, different expansion strategies can be adopted according to the type of edge (reference, application, inheritance, substitution relationship) to ensure the semantic coherence and structural integrity of the graph path, including:

[0108] (1) Reference Edge Expansion Strategy: When encountering a reference edge, the system should prioritize performing a depth search along this edge to ensure that the referenced entity or institutional clause is found. Reference relationships usually indicate a direct dependency between institutions; for example, "Loan Approval Process" references "Customer Due Diligence Requirements." During the expansion process, the system will mark this path as a "direct reference path" and assign a higher similarity weight to the nodes found along this edge, because they are directly related to the inquired institutional clause and provide the direct information needed to answer the question.

[0109] (2) Applicability Relationship Edge Expansion Strategy: Applicability relationship edges point to other entities related to the current entity. For example, "Customer Due Diligence Requirements" may apply to both the "Retail Banking" and "Corporate Banking" departments. When the system encounters such edges, it adopts a breadth-first search (BFS) strategy, that is, it first explores all directly related entities and then delves deeper layer by layer. The breadth exploration of applicability relationships helps to build a more comprehensive semantic context and provide users with the contextual information they may need. However, the expansion of applicability relationship edges should limit the depth to avoid excessively distant entities interfering with the results and to ensure the directness and accuracy of the answer.

[0110] (3) Inheritance Edge Expansion Strategy: An inheritance edge indicates that a new entity (or a new version of the system) inherits the content and attributes of an old entity. For example, the "2024 version of the loan approval process" inherits from the "2023 version of the loan approval process". When the system encounters an inheritance edge, it adopts a time-priority strategy, prioritizing the exploration and consideration of entities that are closer in time (i.e., the new version). If no relevant content is found in the new version, the system will backtrack to the old entity to continue the search. In addition, the system can also record the inheritance path traversed so as to reflect the trajectory of the system's evolution in the final answer, enhancing the authority and traceability of the answer.

[0111] (4) Substitution Relationship Extension Strategy: A substitution relationship edge indicates that one entity (or policy provision) completely or partially replaces another entity. For example, "New Fund Flow Monitoring Policy" replaces "2022 Version of Fund Flow Monitoring Policy". When encountering a substitution relationship edge, the system should adopt a latest-first strategy, directly jumping to the replaced entity, unless the user explicitly requests information about the old entity. Special attention needs to be paid to version control and timestamps when handling substitution relationships to ensure that the system does not return outdated content. The response should clearly indicate whether the entity used is the new or old entity in the substitution relationship to meet compliance and auditability requirements.

[0112] Based on the expansion strategies for the four edge types mentioned above, the system can comprehensively utilize the following methods when performing multi-hop path search:

[0113] (1) Priority sorting: The system can set different search priorities for each edge type. For example, reference relationship edges have the highest priority because they are directly related to the core content of the problem; followed by inheritance relationship edges and substitution relationship edges because they show the evolution and updating of the system; applicable relationship edges have relatively low priority and are used to construct semantic background.

[0114] (2) Dynamic adjustment of depth and breadth: In some embodiments of this application, different search strategies can be set for different types of edges. For example, for reference and substitution relationship edges, the system can adopt a depth-first strategy to explore directly related entities in depth; for application and inheritance relationship edges, a breadth-first strategy can be adopted to explore all directly related entities first, and then go deeper. It should be noted that the system can dynamically adjust the search depth according to the edge type (i.e., determine the stopping condition of the search strategy according to the edge type) to avoid redundant search and information overload.

[0115] (3) Semantic similarity and version timeliness weight: During the expansion process, for each type of edge, the system can combine semantic similarity and version timeliness (such as release time and validity period) to calculate the weight to decide whether to continue searching along the edge. For example, for outdated replacement relationship edges, even if the semantic similarity is high, its weight should not exceed the weight of the new version edge.

[0116] Step S208: Retrieve the document paragraph corresponding to the subgraph region in the sub-index library corresponding to the system module, and input the document paragraph into the large model to generate the target answer corresponding to the query vector.

[0117] In step S208 above, a document paragraph is the smallest searchable unit after the system document is segmented. Each paragraph is converted into a vector representation and stored in the corresponding sub-index library. Its function is to provide information retrieval capability at the smallest granularity, ensuring the accuracy of retrieval results and the readability of recalled documents.

[0118] The large model is responsible for understanding and parsing the user's input question vector, and combining it with document paragraphs retrieved from the knowledge graph to generate the most suitable answer that matches the query requirements and job information. In generating the answer, the large model can perceive and understand the context of the user's role, determining the style, depth, and applicability of the answer based on the job vector. This ensures that the generated answer not only conforms to the professional standards of the financial industry but also meets the specific needs and knowledge permissions of the job, thereby improving the quality of the answer and user satisfaction.

[0119] In some embodiments of this application, combining a large model with job information can generate accurate target answers, specifically:

[0120] (1) Obtaining the job vector: The system first generates a job vector based on the user's identity and job information. This vector contains the user's permission boundaries, business context and job characteristics, which are used to guide the retrieval and generation process.

[0121] (2) Determine the accessible system modules: By comparing the job vector with the vector of each system module, the system determines the system modules that the user can access, ensuring that the document paragraphs within the search scope match the user's job permissions, and preventing the improper exposure of unauthorized information.

[0122] (3) Document retrieval based on subgraph regions: Locate the subgraph region corresponding to the question vector in the knowledge graph. This subgraph region represents the specific knowledge content and logical structure required to answer the question. The system retrieves the most relevant document paragraphs in the sub-index library of the system module related to this region, while ensuring that the metadata tags of these paragraphs (such as version, regional applicability, etc.) match the user's needs.

[0123] (4) Constructing control instructions and constraints: Based on the path information of the retrieved document paragraphs and the user's job information, the system constructs control instructions and constraints. The control instructions guide the model to generate answers according to the logical order in the knowledge graph, while the constraints ensure that the generated answers only contain information that the user has the right to access.

[0124] For example, if a credit manager inquires about the "loan approval process," the system's control instructions might be: "Generate detailed steps of the loan approval process, with particular emphasis on risk assessment and collateral conditions," and set restrictions: "Only reference documents applicable to the credit manager's position, and the documents must be valid."

[0125] (5) Input fusion and answer generation: The user's question vector, control instructions and constraints are input into the big model. The model generates the target answer based on this information. In this process, the big model not only handles natural language issues, but also integrates structured knowledge, job context and access control to ensure the professionalism, accuracy and compliance of the answer content.

[0126] In some embodiments of this application, based on the subgraph region constructed from user questions, the system needs to identify the regulatory module to which the nodes in the subgraph region belong. For example, each node is tagged with business lines and regulatory categories in the knowledge graph, and the system determines the regulatory module to which the node belongs through a tag matching mechanism. Specifically, the node tags in the subgraph region are compared with the tags of each sub-index library to determine which sub-index libraries contain document paragraphs related to the subgraph region. For example, if the subgraph region contains "loan approval" and "risk compliance" nodes, the system will locate the "credit management sub-index library" and the "risk internal control sub-index library".

[0127] In the embodiments of this application, the system determines the policy modules within a user's access scope based on their job title, ensuring that subsequent retrieval operations are only performed within the knowledge domain the user has the right to access. Based on the user's question vector, the retrieval scope is further refined within the sub-index of the determined policy modules. By matching subgraph regions in the knowledge graph, the logical boundaries of the retrieval are limited, ensuring that the recalled document paragraphs are highly relevant to the specific semantic features of the query. Through dual filtering of job title permissions and question semantics, the system can accurately determine which policy documents can be accessed by users in specific positions and which content is most relevant to the question, greatly enhancing the system's security and compliance. The initial filtering limits the physical scope of the retrieval through policy modules, while the second filtering further refines the logical boundaries of the retrieval, significantly reducing the time and computational cost of retrieval operations and improving system response speed and overall performance.

[0128] The filtered document paragraphs are input into a pre-trained large language model. Combined with the vector representation of the user's question, a target answer corresponding to the query vector can be generated. Specifically: the guidance information of the large model is obtained, which includes the path information of the document paragraphs in the knowledge graph and the job information of the target object. The path information is used to indicate the institutional logic and structural order followed by the large model when generating the answer; a target template is constructed based on the guidance information, which includes the control instructions corresponding to the path information and the constraints corresponding to the job information; the large model is used to process the control instructions and constraints to obtain the target answer.

[0129] The guiding information is a data package containing the path information of document paragraphs in the knowledge graph and the target object's job information. Its purpose is to guide the large model in generating answers by following specific institutional logic and structural order, while also considering the user's role and permissions, ensuring that the answers are both accurate and legitimate.

[0130] (1) Path information: The specific path from the question anchor point (i.e. the first graph node) to the recalled document paragraph in the knowledge graph, which is used to control the logical flow and structural framework of the large model to generate answers.

[0131] (2) Job information: The job background of the user's question, which is used to consider job-specific terminology, focus and scope of authority when generating the answer to ensure the job suitability of the answer content.

[0132] The target template, built upon guiding information, is an input template containing control instructions and constraints. It serves as formatted input for large-scale model generation, ensuring that the generated answers adhere to a specific logical structure and semantic boundaries, while also satisfying job-related authority constraints. Control instructions, found in the target template, instruct the large-scale model to generate answers according to the institutional logic and structural order defined in the path information. Constraints, also found in the target template, limit the boundary conditions for the large-scale model's generated answer content, primarily based on the user's job information, ensuring that the answer content not only meets semantic requirements but also satisfies job-related authority and business specifications.

[0133] In some embodiments of this application, complete path information of document paragraphs in the knowledge graph can be extracted based on a determined subgraph region. This includes the starting node, intermediate referencing nodes, ending node, and edge types on the path (such as reference, applicable, inheritance, etc.) to form a path description string. The user's job information (such as "Credit Department Manager") is then converted into a job vector and combined with the path description string to form a complete guidance information data package. For example, for a "Credit Department Manager" asking about the "loan approval process" under the 2024 version of the system framework, the guidance information might include the path information: "Loan Approval Process → Customer Due Diligence Requirements → Approval Authority Settings" and the job information: "Credit Department Manager".

[0134] The system transforms path information into control instructions, which can be specific prompts, sentence frames, or model control parameters to guide the large model to generate answers according to the knowledge structure. For example, for the path information "Loan approval process → Customer due diligence requirements → Approval authority settings", the control instruction might be: "When describing the loan approval process, please include the specific steps for customer due diligence requirements and approval authority settings."

[0135] In addition, it is necessary to set restrictions based on job information in the target template. These restrictions are used to inform the large model users of the job's scope of authority and terminology style to ensure that the answers are job-appropriate. For example, the restrictions may be set as: "The answers must not contain content related to internal audit processes and are limited to policy clauses accessible only to credit department managers."

[0136] By constructing target templates, the system can control the content boundaries and logical flow of large models during the generation process, solving the problems of lack of structural constraints and job suitability in the answer content, while meeting the compliance and accuracy requirements of the financial industry for knowledge dissemination.

[0137] After retrieving the document paragraphs corresponding to the subgraph region in the subindex library corresponding to the policy module, the following steps can be performed: obtain the metadata tags corresponding to the child nodes of the subgraph region, where the metadata tags include the effective date, repeal date, and applicable region of the policy document; if there are multiple versions of the policy document corresponding to the child node, determine the matching score between the policy document corresponding to each version and the query vector based on the metadata tags, where the matching score is used to quantify the applicability of the document paragraph corresponding to each version; determine the target document paragraph for generating the target answer based on the matching score.

[0138] Based on metadata tags, a matching score is determined between the policy document corresponding to each version and the query vector. Specifically: the query time corresponding to the query vector is obtained, and a first indicator is determined based on the query time, the effective time and the repeal time of the version, where the first indicator is used to quantify the timeliness of the version; the query region corresponding to the query vector is obtained, and a second indicator is determined based on the query region and the applicable region of the version, where the second indicator is used to quantify the regional conformity of the version; a third indicator is determined between the question vector in the query vector and the policy document of the version, where the third indicator includes semantic similarity; and a matching score is determined based on the first, second, and third indicators.

[0139] Metadata tags refer to additional information added to nodes in a knowledge graph (especially nodes of policy documents) to describe the characteristics of the nodes, such as the effective date, repeal date, and applicable geographical area of ​​the policy document. Matching scores, when multiple versions of a policy document exist, are a measure of the relevance between each version's document paragraphs and the user's query vector, thus quantifying the applicability of each version.

[0140] Specifically, (1) during the process of processing the content of the system, complete version metadata tags can be added to each system clause and document paragraph, including but not limited to: version ID, start time, end time, applicable region, version policy, etc. These version tags are bound to the nodes in the system map to form a time-series "system evolution path map", which can support functions such as cross-version structure alignment and inheritance relationship tracing.

[0141] (2) During the question-and-answer process, the system performs semantic analysis on the user's question content and context information, and automatically identifies the time information, job information and regional background implied in the question. For example, if the user initiates a question under the identity of "a customer manager of the Beijing branch in October 2024", the system will combine its organizational structure and job responsibilities to automatically limit the question to the subset of documents that are "applicable to the Beijing area and are in effect in October 2024".

[0142] Specifically, the system can score candidate policy versions using the following version matching formula (i.e., matching score): by calculating the semantic similarity between each version of the policy document and the user's question vector, and combining the applicability information regarding time and region in the metadata tags, a matching score is obtained for each version.

[0143]

[0144] in, Question time. To match scores, For the organizational region of the target object, This refers to the applicable region for each version of the policy document. This represents the degree of semantic matching between the question vector and the document paragraph. , , These are the weight parameters.

[0145] The above formula includes factors such as semantic similarity, time window matching degree, and regional applicability. The system ultimately selects the version of the article with the highest score for content generation.

[0146] (3) To ensure the generated results have auditability and consistency with the time context, an "explicit version binding generation template" can also be designed. This means that a structured prompt is automatically appended to the end of the generated answer content in the large model, such as: This answer is generated in accordance with Article 7 of the "Guidelines for Credit Customer Classification" (revised in September 2024), applicable to customer managers in the A city area, and the current version is effective from September 1, 2024 to August 31, 2025. This mechanism not only enhances the credibility and authority of the answer content, but also provides a basis for systematic audit retrospective and accountability tracking. Even if the system content is updated again later, the historical Q&A records can still be restored and compared according to the version label, supporting accountability management and operational review during the system transition period.

[0147] Through steps S202 to S208, a method integrating job information and query requirements is adopted. By generating a query vector containing question vectors and job vectors, the system modules that match the target job are selected. The subgraph region corresponding to the question vector is located in the knowledge graph. Then, a refined document paragraph retrieval is performed in the sub-index library corresponding to the selected system module. These paragraphs are used as context input into the large model to generate answers. This achieves the goal of accurately matching user queries with accessible system modules and precisely defining the logical boundaries of semantic retrieval. Thus, it realizes the technical effect of generating enhanced question-and-answer content with job suitability and system compliance, improving retrieval efficiency and answer accuracy. This solves the technical problem that the question-and-answer system used in related technologies lacks the identification of user job identity and cannot provide matching answers according to the different job responsibilities and permissions of financial branches.

[0148] This application also provides a modular knowledge graph and retrieval-enhanced large-scale model fusion interactive system for financial branches, including an interactive device and a server. The interactive device, connected to the server, is used to obtain a query vector for a target object. The query vector includes a question vector describing the target object's query needs and a job vector reflecting the target object's job information within the financial branch. The server, connected to the interactive device, is used to determine the policy modules accessible to the target object based on the job vectors. Each policy module is a unit logically divided according to the business domain of the financial branch. The system then determines a subgraph region in the knowledge graph corresponding to the question vector, where the knowledge graph represents the logical structure between policy documents. Finally, it retrieves document paragraphs corresponding to the subgraph region from the sub-index library corresponding to the policy module and inputs these document paragraphs into the large-scale model to generate the target answer corresponding to the query vector.

[0149] It should be noted that the aforementioned modular knowledge graph and retrieval-enhanced large-scale model fusion and interaction system for financial branches is used for execution Figure 2 The method shown is a modular knowledge graph and retrieval-enhanced large model fusion and interaction approach for financial branches, therefore... Figure 2 The explanations and descriptions in the modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches also apply to the above-mentioned modular knowledge graph and retrieval-enhanced large model fusion and interaction system for financial branches, and will not be repeated here.

[0150] Figure 3 This is a structural diagram of a modular knowledge graph and retrieval-enhanced large model fusion and interaction device for financial branches, according to an embodiment of this application. Figure 3 As shown, the device includes:

[0151] The acquisition module 302 is used to acquire the query vector of the target object, wherein the query vector includes a question vector that describes the query requirements of the target object and a job vector that reflects the job information of the target object in the financial branch.

[0152] Module 304 is used to determine the system modules accessible to the target object based on the job vector. The system modules are units that logically divide system documents according to the business areas of financial branches.

[0153] The matching module 306 is used to determine the subgraph region corresponding to the question vector in the knowledge graph, wherein the knowledge graph is used to represent the logical structure between institutional documents;

[0154] The interaction module 308 is used to retrieve the document paragraphs corresponding to the subgraph regions in the sub-index library corresponding to the system module, and input the document paragraphs into the large model to generate the target answer corresponding to the query vector.

[0155] It should be noted that, Figure 3 The modular knowledge graph and retrieval-enhanced large model fusion interactive device shown is used for financial branch offices to perform... Figure 2 The method shown is a modular knowledge graph and retrieval-enhanced large model fusion and interaction approach for financial branches, therefore... Figure 2 The relevant explanations in the modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches also apply to... Figure 3 The modular knowledge graph and retrieval-enhanced large model fusion interactive device for financial branches shown here will not be described in detail here.

[0156] This application also provides an electronic device, which includes a memory and a processor. The memory is used to store program instructions, and the processor is connected to the memory to execute the steps of implementing the modular knowledge graph and retrieval-enhanced large model fusion interaction method for financial branches in various embodiments of this application.

[0157] This application also provides a non-volatile storage medium, which includes a stored computer program. The device containing the non-volatile storage medium executes the steps of the modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches in various embodiments of this application by running the computer program.

[0158] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches in various embodiments of this application.

[0159] This application also provides a computer program that, when executed by a processor, implements the steps of the modular knowledge graph and retrieval-enhanced large model fusion and interaction method for financial branches in various embodiments of this application.

[0160] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0161] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0162] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0163] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0164] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0165] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0166] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A modular knowledge graph and retrieval enhanced large model fusion interaction method for financial branches, characterized in that, The method comprises the following steps: acquiring a query vector of a target object, wherein the query vector comprises a question vector for expressing a query requirement of the target object and a post vector for reflecting post information of the target object in a financial branch; determining a system module accessible to the target object according to the post vector, wherein the system module is a unit logically divided according to a business field of the financial branch; determining a subgraph area corresponding to the question vector in a knowledge graph, wherein the knowledge graph is used to represent a logical structure between system documents; retrieving a document paragraph corresponding to the subgraph area in a sub-index library corresponding to the system module, and inputting the document paragraph into a large model to generate a target answer corresponding to the query vector; wherein, determining the system module accessible to the target object according to the post vector comprises: acquiring multi-dimensional labels corresponding to all system modules respectively, wherein the multi-dimensional labels comprise a business field label for limiting the applicable range of system documents, a business line attribute label for refining the business line under the business field, and a post applicability label for limiting access authority; determining the similarity between the post vector and the multi-dimensional labels, and comparing the post authority information in the post vector with the post applicability label to obtain a comparison result; determining the system module accessible to the target object according to the similarity and the comparison result, wherein each system module corresponds to a sub-index library, and the sub-index library is used to store the system documents corresponding to the system module; wherein, inputting the document paragraph into the large model to generate the target answer corresponding to the query vector comprises: acquiring guide information of the large model, wherein the guide information comprises path information of the document paragraph in the knowledge graph and post information of the target object, and the path information is used to indicate the system logic and structure order followed by the large model when generating the answer; constructing a target template according to the guide information, wherein the target template comprises control instructions corresponding to the path information and restriction conditions corresponding to the post information; processing the control instructions and the restriction conditions by using the large model to obtain the target answer.

2. The method of claim 1, wherein, The knowledge graph is constructed by the following method: extracting entities from a system document set, wherein the entities comprise system clauses; determining relationships between the entities, and determining edges of the knowledge graph according to the relationships, wherein the relationships comprise one of the following: reference relationship, applicability relationship, inheritance relationship and replacement relationship between the system clauses; constructing the knowledge graph according to the entities and the edges.

3. The method of claim 2, wherein, determining the subgraph area corresponding to the question vector in the knowledge graph comprises: matching the question vector with the knowledge graph to obtain a first graph node, wherein the first graph node comprises a node with a similarity greater than or equal to a first preset threshold to the semantic features of the question vector; According to the edge of the knowledge graph, a graph path is searched from the first graph node, and the search is stopped when a stop condition is met, to obtain a second graph node set, wherein the stop condition includes that a semantic feature similarity between a second graph node and the question vector is less than a second preset threshold, and the second preset threshold is less than the first preset threshold; According to the first graph node and the second graph set, the subgraph region is determined.

4. The method of claim 1, wherein, After retrieving the document paragraphs corresponding to the subgraph region in the sub-index library corresponding to the system module, the method further comprises: Obtaining metadata tags corresponding to the subnodes of the subgraph region, wherein the metadata tags include the effective time, the expiration time, and the applicable region of the system document; In the case that there are multiple versions of the system document corresponding to the subnode, determining a matching score between the system document corresponding to each version and the query vector according to the metadata tags, wherein the matching score quantitatively represents the applicability of the document paragraph corresponding to each version; According to the matching score, a target document paragraph used to generate the target answer is determined.

5. The method of claim 4, wherein, Determining a matching score between the system document corresponding to each version and the query vector according to the metadata tags comprises: Obtaining a query time corresponding to the query vector, and determining a first indicator according to the query time, the effective time, and the expiration time of the version, wherein the first indicator quantitatively represents the timeliness of the version; Obtaining a query region corresponding to the query vector, and determining a second indicator according to the query region and the applicable region of the version, wherein the second indicator quantitatively represents the regional compliance degree of the version; Determining a third indicator between the question vector in the query vector and the system document of the version, wherein the third indicator includes semantic similarity; According to the first indicator, the second indicator, and the third indicator, the matching score is determined.

6. A modular knowledge graph and retrieval enhanced large model fusion interaction system for financial branches, characterized in that, Comprising an interactive device and a server, wherein, The interactive device, connected to the server, is configured to obtain a query vector of a target object, wherein the query vector includes a question vector used to express the query demand of the target object and a post vector used to reflect the post information of the target object in a financial branch; The server, connected to the interactive device, is configured to determine a system module accessible to the target object according to the post vector, wherein the system module is a unit logically divided according to the business field of the financial branch; determine a subgraph region corresponding to the question vector in a knowledge graph, wherein the knowledge graph is used to represent the logical structure between the system documents; retrieve document paragraphs corresponding to the subgraph region in a sub-index library corresponding to the system module, and input the document paragraphs into a large model to generate a target answer corresponding to the query vector. The system module accessible by the target object is determined according to the post vector, including: obtaining multi-dimensional tags corresponding to all system modules respectively, wherein the multi-dimensional tags include a business domain tag for limiting the applicable scope of a system document, a strip line attribute tag for refining a business line under the business domain, and a post applicability tag for limiting access authority; determining the similarity between the post vector and the multi-dimensional tags, and comparing the post authority information in the post vector with the post applicability tag to obtain a comparison result; determining the system module accessible by the target object according to the similarity and the comparison result, wherein each system module corresponds to a sub-index library, and the sub-index library is used to store the system document corresponding to the system module; The document paragraph is input into a large model to generate a target answer corresponding to the query vector, including: obtaining guide information of the large model, wherein the guide information includes path information of the document paragraph in the knowledge graph and post information of the target object, and the path information is used to indicate the system logic and structure order followed by the large model when generating an answer; constructing a target template according to the guide information, wherein the target template includes control instructions corresponding to the path information and restriction conditions corresponding to the post information; and processing the control instructions and the restriction conditions by using the large model to obtain the target answer.

7. A modular knowledge graph and retrieval enhanced large model fusion interaction device for financial branches, characterized in that, The system includes: An acquisition module is configured to acquire a query vector of a target object, wherein the query vector includes a problem vector for expressing a query demand of the target object and a post vector for reflecting post information of the target object in a financial branch. A determination module is configured to determine a system module accessible by the target object according to the post vector, wherein the system module is a unit obtained by logically dividing system documents according to a business domain of the financial branch, and wherein the determination of the system module accessible by the target object according to the post vector includes: obtaining multi-dimensional tags corresponding to all system modules respectively, wherein the multi-dimensional tags include a business domain tag for limiting the applicable scope of a system document, a strip line attribute tag for refining a business line under the business domain, and a post applicability tag for limiting access authority; determining the similarity between the post vector and the multi-dimensional tags, and comparing the post authority information in the post vector with the post applicability tag to obtain a comparison result; determining the system module accessible by the target object according to the similarity and the comparison result, wherein each system module corresponds to a sub-index library, and the sub-index library is used to store the system document corresponding to the system module. A matching module is configured to determine a subgraph area corresponding to the problem vector in a knowledge graph, wherein the knowledge graph is used to represent the logical structure between the system documents. An interaction module is configured to search for a document paragraph corresponding to the subgraph region in a subindex library corresponding to the system module, and input the document paragraph into a large model to generate a target answer corresponding to the query vector. The inputting of the document paragraph into the large model to generate the target answer corresponding to the query vector includes: obtaining guide information of the large model, wherein the guide information includes path information of the document paragraph in the knowledge graph and post information of the target object, and the path information is used to indicate a system logic and a structure order followed by the large model when generating the answer; constructing a target template according to the guide information, wherein the target template includes control instructions corresponding to the path information and restriction conditions corresponding to the post information; and processing the control instructions and the restriction conditions by using the large model to obtain the target answer.

8. An electronic device, comprising: Comprise: A memory and a processor, the memory is used for storing program instructions; the processor is connected with the memory, and is used for executing the modular knowledge graph and retrieval enhanced large model fusion interaction method for financial branch institutions in any one of claims 1 to 5.

9. A non-volatile storage medium, comprising: The non-volatile storage medium includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the modular knowledge graph and retrieval enhanced large model fusion interaction method for financial branch institutions in any one of claims 1 to 5 by running the computer program.

10. A computer program product comprising computer instructions, characterized in that, The computer instructions are executed by the processor to implement the modular knowledge graph and retrieval enhanced large model fusion interaction method for financial branch institutions in any one of claims 1 to 5.

Images