An information processing method, apparatus, device, and medium

Abstract

The application discloses an information processing method, device, equipment and medium to improve the accuracy of information reasoning. The application retrieves a set of knowledge fragments matched with the question submitted by the user through a retrieval module; for each knowledge fragment in the set of knowledge fragments, the corresponding document fragment is located using the knowledge fragment to generate a set of document fragments; the set of document fragments is placed in a co-occurrence relationship graph to obtain a high-frequency co-occurrence community and perform training to generate a LoRA plug-in corresponding to the target high-frequency co-occurrence community; the question information is generated using the set of knowledge fragments and the question submitted by the user; the corresponding set of LoRA plug-ins is located according to the set of knowledge fragments to determine the plug-in set information of the set of LoRA plug-ins; the question is generated using the question information and the plug-in set information and sent to an LLM cluster; the target LLM is routed based on the plug-in set information in the question through the LLM cluster, and the target LLM loads the LoRA plug-in to reason the question.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to an information processing method, apparatus, device and medium. Background Technology

[0002] Current domain-specific adaptation techniques for large models can be mainly divided into the following three mainstream paths: One approach is the efficient parameter fine-tuning technique represented by LoRA (Low-Rank Adaptation). This technique freezes the weights of the pre-trained model and performs incremental training only by inserting low-rank matrices into specific layers, significantly reducing computational resource consumption. In practical applications, batch training is typically performed based on a selected set of domain documents, and the generated LoRA plugins are loaded into the model to enhance its domain-specific capabilities. Its core architecture includes a data preprocessing module, a low-rank matrix training engine, a LoRA plugin storage and loading component, and an inference adaptation layer.

[0003] Second is RAG (Retrieval-Augmented Generation) retrieval enhancement technology. This technology constructs a domain knowledge base index and retrieves knowledge fragments related to the user's question in real time during the inference stage, using them as context input for the model to generate answers. Typical implementations include a document chunker, vector encoder, vector database, retrieval ranking module, and LLM (Large Language Models) interface. Some solutions introduce semantic re-ranking models to improve retrieval accuracy.

[0004] Thirdly, there's GraphRAG (Graph-Based Retrieval-Augmented Generation) technology. As an advanced form of RAG, it constructs an entity and relationship network through a knowledge graph, uses community detection algorithms to divide semantically related units, and extracts relevant subgraphs during retrieval, converting them into natural language to assist in reasoning. The system architecture includes an entity relationship extractor, a graph database, a community analysis engine, and a subgraph serialization module.

[0005] In the domain-specific applications of large language models, the synergistic improvement of knowledge adaptation efficiency and inference accuracy remains a core challenge. With the exponential growth of enterprise-level knowledge scale, relying solely on LoRA (Low-Rank Adaptation) for fine-tuning faces problems such as high training costs and poor dynamic adaptability. Employing RAG (Retrieval-Augmented Generation) and its advanced form GraphRAG (Graph-Based Retrieval-Augmented Generation) alone is constrained by the contradiction between knowledge fragmentation and context overload.

[0006] In summary, existing technologies cannot simultaneously meet the comprehensive needs of deep knowledge internalization, real-time dynamic adaptation, and efficient reasoning. This often leads to enterprises encountering dilemmas during model optimization, such as long training cycles with slow results or fast retrieval responses with insufficient depth. Summary of the Invention

[0007] This application provides an information processing method, apparatus, device, and medium to integrate dynamic LoRA fine-tuning based on knowledge co-occurrence communities with information retrieval, effectively improving the training efficiency of LoRA plugins, the accuracy of information reasoning, and their dynamic adaptability.

[0008] This application provides an information processing method for processing user-submitted questions, the method comprising: The user submits a question, which is then input into the search module, which retrieves a set of matching knowledge fragments. For each knowledge fragment in the knowledge fragment set, the corresponding document fragment is located using the knowledge fragment, generating a document fragment set including at least one document fragment; the document fragment set is placed into a co-occurrence graph, and high-frequency co-occurrence community analysis is performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community; a target high-frequency co-occurrence community is selected from the at least one high-frequency co-occurrence community for training, generating a LoRA plugin corresponding to the target high-frequency co-occurrence community; Furthermore, the system generates question information using the knowledge fragment set and the user-submitted question; locates the corresponding LoRA plugin set based on the knowledge fragment set and determines the plugin set information of that LoRA plugin set; generates a question using the question information and the plugin set information, and sends the question to the LLM cluster; through the load balancing server in the LLM cluster, based on the plugin set information in the question, routes the question to the target LLM, loads the LoRA plugin in the target LLM to perform reasoning on the question, and generates answer content to be output to the user.

[0009] As can be seen, the method provided in this application embodiment realizes a fusion of dynamic LoRA fine-tuning based on knowledge co-occurrence community and information retrieval, used to process user-raised questions and provide corresponding answers. Specifically, the user-submitted question is input into the retrieval module, which retrieves a matching set of knowledge fragments. For each knowledge fragment in the set, the corresponding document fragment is located using that knowledge fragment, generating a document fragment set including at least one document fragment. The document fragment set is placed into a co-occurrence graph, and high-frequency co-occurrence community analysis is performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community. A target high-frequency co-occurrence community is selected from the at least one high-frequency co-occurrence community for training, generating a LoRA plugin corresponding to the target high-frequency co-occurrence community. Question information is generated using the knowledge fragment set and the user-submitted question. Furthermore, the corresponding LoRA plugin set is located based on the knowledge fragment set, and the plugin set information of the LoRA plugin set is determined. A question is generated using the question information and the plugin set information, and the question is sent to the LLM cluster. Through the load balancing server in the LLM cluster, based on the plugin set information in the question, the question is routed to a target LLM, which loads the LoRA plugin to perform inference on the question, generating answer content to be output to the user. Therefore, the information processing method for handling user-submitted questions provided in this application can provide search results to users while also enabling dynamic LoRA fine-tuning based on knowledge co-occurrence communities. This constructs a complete closed-loop mechanism of "retrieval-co-occurrence analysis-dynamic fine-tuning-intelligent routing," providing key technical support for domain-specific adaptation of large models, breaking through the limitations of technical fragmentation, achieving collaborative linkage and efficient circulation among various links, ensuring deep internalization of domain knowledge and real-time dynamic adaptation, effectively improving the training efficiency of LoRA plugins, the accuracy of information reasoning, and the dynamic adaptability between training LoRA plugins and information reasoning.

[0010] In some implementations, high-frequency co-occurrence community analysis is performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community, including: The co-occurrence relationship graph of document fragments is constructed or updated using the co-occurrence relationship graph; According to preset rules, high-frequency co-occurrence communities are detected for the co-occurrence relationship graph of the document fragments.

[0011] In some implementations, the document fragment co-occurrence graph includes multiple nodes, each node being a document fragment; The construction of the document fragment co-occurrence graph includes: The RAG component outputs at least one knowledge fragment related to the question raised by the user. Determine the document segment corresponding to each of the aforementioned knowledge segments; Based on document fragments that have co-occurrence relationships, a document fragment co-occurrence relationship graph is determined, where the nodes of the document fragment co-occurrence relationship graph are document fragments, and the edges between nodes indicate that there is a co-occurrence relationship between document fragments.

[0012] In some implementations, constructing the co-occurrence graph of the document fragments further includes determining the weights of the edges between nodes in the following manner: For every two nodes, the number of times the document fragments of these two nodes co-occur is determined as the basic weight; based on the basic weight and the time decay factor, the weight of the edge between these two nodes is determined.

[0013] In some implementations, the time decay factor is a value that is dynamically adjusted based on the interval between the co-occurrence time of the document fragments of the two nodes and the current time.

[0014] In some implementations, updating the document fragment co-occurrence graph includes: For each knowledge fragment, locate the corresponding document fragment based on the position of the knowledge fragment in the document; For each document fragment located, check whether the document fragment already exists in the document fragment co-occurrence relationship graph; if it does not exist, add a node for the document fragment in the document fragment co-occurrence relationship graph and initialize the attribute information of the document fragment; if it already exists, update the attribute information of the document fragment. For any pairwise relationships between all located document fragments, if there is no co-occurrence edge in the document fragment co-occurrence graph, a new edge is created and its weight is initialized; if a co-occurrence edge already exists, its attribute information is updated based on this co-occurrence behavior.

[0015] In some implementations, the preset rules include one or a combination of the following rules: According to a preset period, high-frequency co-occurrence communities are periodically detected for the co-occurrence relationship graph of the document fragments; When the number of newly added nodes in the document fragment co-occurrence graph exceeds a preset threshold, high-frequency co-occurrence communities are detected for the document fragment co-occurrence graph.

[0016] In some implementations, for the co-occurrence graph of the document fragments, high-frequency co-occurrence communities are detected, including: The document fragment co-occurrence graph was divided into high-frequency co-occurrence communities using the Leiden algorithm, resulting in at least one high-frequency co-occurrence community. Determine the overall weight of each of the aforementioned high-frequency co-occurrence communities.

[0017] In some implementations, determining the overall weight of each of the high-frequency co-occurrence communities includes: For each of the aforementioned high-frequency co-occurrence communities, a weighted sum is performed based on one or a combination of the following parameters of the high-frequency co-occurrence community to obtain the comprehensive weight of the high-frequency co-occurrence community: This includes the total number of occurrences of all nodes within the high-frequency co-occurrence community, the total weight of edges, and the average retrieval ranking of document fragments.

[0018] In some implementations, a target high-frequency co-occurrence community is selected from the at least one high-frequency co-occurrence community for training, generating a LoRA plugin corresponding to the target high-frequency co-occurrence community: Select the high-frequency co-occurrence community with the highest comprehensive weight from the at least one high-frequency co-occurrence community as the target high-frequency co-occurrence community; For each document involved in the target high-frequency co-occurrence community, determine the set of document fragments of that document in the target high-frequency co-occurrence community, extract the training content from the set of document fragments through the GraphRAG knowledge graph of that document, and generate the training document based on the extracted training content and the structure of the document. A training document set is generated using the training documents of each document involved in the target high-frequency co-occurrence community; The document set to be trained is input into LoRA, and the LoRA plugin is obtained through LoRA training.

[0019] In some implementations, for each document involved in a target high-frequency co-occurrence community, training content is extracted from the document fragment set using the document's GraphRAG knowledge graph. Based on the extracted training content and the document's structure, a training document is generated, including: For each document involved in the target high-frequency co-occurrence community: The document was preprocessed using GraphRAG; Based on the preprocessed document, a GraphRAG knowledge graph is generated, wherein the GraphRAG knowledge graph includes multiple text blocks obtained by segmenting the document; For each document fragment in the document fragment set, locate the corresponding text block in the GraphRAG knowledge graph, and obtain the GraphRAG semantic community to which the text block belongs based on the entities and relationships associated with the text block; The text blocks corresponding to all entities and relations contained in each GraphRAG semantic community are included in the set of text blocks to be trained; For each text block in the set of text blocks to be trained, expand to the text blocks adjacent to it before and after the text block to form an expansion unit; For the target document that has undergone the preprocessing, its hierarchical structure and the content of each expansion unit are preserved. For the document area outside each expansion unit, a preset tag is used for replacement, and finally the training document corresponding to the target document is formed.

[0020] In some implementations, a GraphRAG knowledge graph is generated based on the preprocessed documents, including: The preprocessed document is then divided into multiple text blocks according to its hierarchical structure. The LLM is invoked to process each text block, identify the entities within them, extract the relationships between the entities, obtain entity and relationship instances, and use the entity and relationship instances to initially construct the GraphRAG knowledge graph; The entities in the GraphRAG knowledge graph are grouped, and each group forms a semantic community. Generate a summary for each of the semantic communities; The text blocks and entities in the knowledge graph are converted into vectors and stored in a vector database. The GraphRAG knowledge graph, which contains structured data of the entities, relationships, and semantic communities, will be persistently stored.

[0021] In some implementations, the corresponding LoRA plugin set is located based on the knowledge fragment set, and the plugin set information of the LoRA plugin set is determined, including: For each knowledge fragment in the knowledge fragment set, the corresponding document region is located based on the document and location information of the knowledge fragment, and the LoRA plugin corresponding to the knowledge fragment is determined based on the mapping relationship between the document region and the LoRA plugin. Using the LoRA plugins corresponding to each knowledge fragment in the knowledge fragment set, a LoRA plugin set is generated; By using the plugin information and weight information of each LoRA plugin in the LoRA plugin set, the plugin set information of the LoRA plugin set is generated.

[0022] In some implementations, the mapping relationship between the document region and the LoRA plugin is maintained through an inverted index of the LoRA plugin and the document region, where the document region identifier is the key and the LoRA plugin identifier is the value.

[0023] In some implementations, the query is routed to the target LLM based on the plugin set information in the query via a load balancer in the LLM cluster, including: By using the load balancing server in the LLM cluster, based on the LoRA plugin loading status and load of each LLM node, it is determined whether there is a target LLM node that has loaded all the required LoRA plugins that match the plugin set information and whose load is lower than a preset threshold. If it exists, the query will be routed to the target LLM; If none exists, the LLM with the most loaded plugins matching the plugin set information is identified as the target LLM, and a LoRA plugin loading instruction is sent to the target LLM node to instruct it to load the plugins not loaded in the plugin set information. After the target LLM node has completed loading all the required LoRA plugins matching the plugin set information, the query is routed to the target LLM.

[0024] In some implementations, the LoRA plugin is loaded into the target LLM to perform reasoning on the question and generate an answer to be output to the user, including: For each LoRA plugin in the plugin set information, the influence coefficient of the LoRA plugin is set according to the weight information of the LoRA plugin; wherein, the higher the weight of the LoRA plugin, the greater the influence coefficient. Based on the influence coefficient of each LoRA plugin in the plugin set information, answer content is generated for output to the user, wherein the larger the influence coefficient of a LoRA plugin, the greater the influence of the LoRA plugin on the answer content.

[0025] In some implementations, the weight information of the LoRA plugin is determined in the following way: For high-frequency co-occurrence communities that directly match the question, the corresponding LoRA plugin weight is positively correlated with the number of knowledge fragments matched by the high-frequency co-occurrence community in this RAG search. The more knowledge fragments matched, the higher the corresponding plugin weight. For high-frequency co-occurrence communities that do not directly match the question, the LoRA plugin weight corresponding to the high-frequency co-occurrence community that does not directly match is calculated by combining the plugin weight of the matched high-frequency co-occurrence communities and the total correlation between the high-frequency co-occurrence communities that do not directly match and the matched high-frequency co-occurrence communities. The total correlation is determined by summarizing the correlation between each high-frequency co-occurrence community that is periodically maintained. If the total correlation between a non-directly matched high-frequency co-occurrence community and a matched high-frequency co-occurrence community is lower than a preset threshold, the weight of the LoRA plugin corresponding to the non-directly matched high-frequency co-occurrence community is set to 0.

[0026] This application provides an information processing device for processing user-submitted questions, the device comprising: The knowledge fragment set generation module is used to input the questions submitted by users into the retrieval module, and the retrieval module retrieves the matching knowledge fragment set. The fine-tuning training processing module is used to locate the corresponding document fragment for each knowledge fragment in the knowledge fragment set, generate a document fragment set including at least one document fragment; place the document fragment set into a co-occurrence relation graph, perform high-frequency co-occurrence community analysis on the co-occurrence relation graph to obtain at least one high-frequency co-occurrence community; select a target high-frequency co-occurrence community from the at least one high-frequency co-occurrence community for training, and generate the LoRA plugin corresponding to the target high-frequency co-occurrence community; The reasoning question-answering processing module is used to generate question information using the knowledge fragment set and the question submitted by the user; and to locate the corresponding LoRA plugin set based on the knowledge fragment set, and determine the plugin set information of the LoRA plugin set; to generate a question using the question information and the plugin set information, and send the question to the LLM cluster; through the load balancing server in the LLM cluster, based on the plugin set information in the question, the question is routed to the target LLM, and the target LLM loads the LoRA plugin to reason about the question, generating answer content to be output to the user.

[0027] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory is used to store program instructions, and the processor is used to call the program instructions stored in the memory and execute any of the methods described above according to the obtained program.

[0028] Another embodiment of this application provides a computer-readable storage medium storing computer-executable instructions for causing the computer to perform any of the methods described above. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 A flowchart illustrating an information processing method provided in an embodiment of this application; Figure 2 A flowchart illustrating another information processing method provided in an embodiment of this application; Figure 3 A schematic diagram illustrating the collaborative processing flow of the various components provided in the embodiments of this application; Figure 4 This is a schematic diagram of the training-level information flow processing flow provided in the embodiments of this application; Figure 5 This is a schematic diagram of the information processing flow provided in the embodiments of this application; Figure 6 A schematic diagram illustrating the process of generating a set of documents to be trained, provided for an embodiment of this application; Figure 7 A schematic diagram of the GraphRAG indexing stage processing flow provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0032] This application provides an information processing method, apparatus, device, and medium to integrate dynamic LoRA fine-tuning based on knowledge co-occurrence communities with information retrieval, effectively improving the training efficiency of LoRA plugins, the accuracy of information reasoning, and their dynamic adaptability.

[0033] The methods, apparatus, equipment, and media are based on the same concept of the application. Since the methods, apparatus, equipment, and media solve problems in similar principles, the implementation of the apparatus, equipment, media, and methods can refer to each other, and repeated parts will not be described again.

[0034] The terms "first," "second," etc. (if present) 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 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 a 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.

[0035] The following examples and embodiments are to be understood as illustrative only. While this specification may refer to "a," "an," or "some" examples or embodiments in several places, this does not mean that every such reference relates to the same example or embodiment, nor does it mean that the feature applies only to a single example or embodiment. Individual features of different embodiments may also be combined to provide other embodiments. Furthermore, terms such as "comprising" and "including" should be understood not to limit the described embodiments to consisting only of those features mentioned; such examples and embodiments may also include features, structures, units, modules, etc., not specifically mentioned.

[0036] The various embodiments of this application will now be described in detail with reference to the accompanying drawings. It should be noted that the order in which the embodiments are presented in this application represents only a chronological order and does not represent the superiority or inferiority of the technical solutions provided by the embodiments.

[0037] LoRA fine-tuning technology has three limitations: First, training data relies on manual or other methods of selection, which is limited by the knowledge boundaries of the selectors and other practical factors, resulting in a deviation between the training scope and the actual usage, leading to an imbalance between training efficiency and knowledge coverage. Second, LoRA plugin loading lacks dynamism, and the simultaneous activation of multiple domain LoRA plugins can easily lead to weight dilution and semantic conflicts, especially when the parameters of irrelevant LoRA plugins are highly strong, which can significantly deviate from the target task. Third, expanding the training data coverage to alleviate the bias in the training scope will increase computational overhead, significantly prolong the training cycle, and ultimately make it difficult to keep up with the rapid iteration of the model, creating a contradiction between scope expansion and iterative adaptation.

[0038] The core problem with RAG technology lies in the contradiction between knowledge fragmentation and context length. When only a retrieval fragment is passed in, deep logical connections are severed, making it difficult to support complex reasoning; if it is expanded to the full-text context, it will lead to the dilution of key information and a decrease in reasoning efficiency, resulting in cluster performance bottlenecks in concurrent scenarios.

[0039] While GraphRAG alleviates the fragmentation problem through entity relationship networks, it still has limitations: it is difficult to balance graph density, with dense graphs leading to information overload and sparse graphs missing key relationships; entity relationship extraction tends to simplify complex semantics, and path decay occurs when expanding multi-level relationships, causing distant but important relationships to be ignored; the length of the context after subgraph serialization may still exceed the efficient reasoning range, continuing the inherent defects of long contexts; and the graph structure constructed by GraphRAG, due to the fine granularity and large number of entity relationships, limits its ability to support massive amounts of documents.

[0040] When applied individually, none of the three technologies mentioned above can simultaneously meet the comprehensive requirements of deep knowledge internalization, dynamic adaptation, and efficient reasoning. There is an urgent need to build a new domain-specific adaptation device that can integrate knowledge co-occurrence analysis, dynamic LoRA training, and intelligent routing loading of LoRA plugins. Through the dynamic optimization of knowledge unit correlation mining and fine-tuning strategies, a breakthrough improvement in the domain adaptation performance of large models can be achieved.

[0041] The information processing method proposed in this application integrates dynamic LoRA fine-tuning based on knowledge co-occurrence communities with information retrieval, constructs a complete closed-loop mechanism of "retrieval-co-occurrence analysis-dynamic fine-tuning-intelligent routing", provides key technical support for the domain-specific adaptation of large models, breaks through the limitations of technical fragmentation, and realizes the coordinated linkage and efficient circulation of each link.

[0042] This application's embodiments take user queries as the triggering point. While acquiring knowledge fragments to support reasoning through the RAG component, it simultaneously models the co-occurrence relationships of the retrieved fragments. The Leiden algorithm is used to identify high-frequency co-occurrence communities. These communities not only match the user's frequently interested areas but also serve as core data units for LoRA fine-tuning, resolving the discrepancy between training data selection and actual use. Furthermore, relying on GraphRAG's entity relationship network and document hierarchy mapping, the semantic community is located through associated entities and relationships. Then, the training units are constructed through the entity relationships contained in the community and adjacent extensions, generating a training document set that preserves document logic and contextual associations, providing high-interest, high-value training data for LoRA fine-tuning.

[0043] In this embodiment, the mapping between the generated LoRA plugins and document regions is fine-tuned. Subsequent new queries triggering RAG retrieval of relevant fragments can quickly match the corresponding LoRA plugin information set. The load balancer in the LLM cluster dynamically routes to the appropriate LLM nodes based on the LoRA plugin matching and load, simultaneously driving real-time loading of LoRA plugins and setting LoRA plugin weights at the message granularity to avoid interference from irrelevant LoRA plugins. Furthermore, the continuous evolution of the knowledge community will drive incremental fine-tuning of the community.

[0044] The embodiments of this application achieve full-process automation, ensuring deep internalization of domain knowledge and real-time dynamic adaptation, effectively improving training efficiency, inference accuracy and dynamic adaptability.

[0045] The technical solutions provided in the embodiments of this application are illustrated below with reference to the accompanying drawings.

[0046] Example 1: See Figure 1 This application provides an information processing method for processing user-submitted questions, the method comprising: S101. Input the question submitted by the user into the retrieval module, and retrieve the matching set of knowledge fragments through the retrieval module; The retrieval module includes, for example, a vector database and a RAG component. RAG is a method combining retrieval technology and a generative model. It first retrieves knowledge fragments relevant to the user's query from a knowledge base, then uses these fragments as context input to the generative model, assisting the model in generating more accurate and evidence-based responses. In this embodiment, the RAG component is the core component for triggering co-occurrence relationship analysis and obtaining supporting reasoning fragments. The retrieval results are directly used for co-occurrence relationship graph construction and subsequent LoRA plugin matching. The RAG component obtains a set of original knowledge fragments matching the user's submitted question by calling the vector database.

[0047] S102. For each knowledge fragment in the knowledge fragment set, locate the corresponding document fragment using the knowledge fragment to generate a document fragment set including at least one document fragment; place the document fragment set into a co-occurrence relation graph, perform high-frequency co-occurrence community analysis on the co-occurrence relation graph to obtain at least one high-frequency co-occurrence community; select a target high-frequency co-occurrence community from the at least one high-frequency co-occurrence community for training, and generate a LoRA plugin corresponding to the target high-frequency co-occurrence community; S103. Generate question information using the knowledge fragment set and the question submitted by the user; and locate the corresponding LoRA plugin set according to the knowledge fragment set, and determine the plugin set information of the LoRA plugin set; generate a question using the question information and the plugin set information, and send the question to the LLM cluster; through the load balancing server in the LLM cluster, based on the plugin set information in the question, route the question to the target LLM, and use the target LLM to load the LoRA plugin to reason about the question and generate answer content to be output to the user.

[0048] It should be noted that step S102 involves fine-tuning training, and step S103 involves reasoning and question answering. These two steps can be executed in parallel or sequentially, and the order of the steps is not fixed.

[0049] The high-frequency co-occurrence community refers to a network structure in which certain keywords or concepts frequently co-occur in a specific domain or text, forming a closely related network. Therefore, in this embodiment, the high-frequency co-occurrence community can refer to a group of nodes in a co-occurrence graph, where nodes (i.e., document fragments) within the group exhibit high-frequency co-occurrence relationships.

[0050] Example 2: See Figure 2 The information processing method provided in this embodiment includes: S201. Input the question submitted by the user into the retrieval module, and retrieve the matching set of knowledge fragments through the retrieval module; S202. For each knowledge fragment in the knowledge fragment set, use that knowledge fragment to locate the corresponding document fragment, and generate a document fragment set that includes at least one document fragment. S203. Place the document fragment set into a co-occurrence graph, perform high-frequency co-occurrence community analysis on the co-occurrence graph, and obtain at least one high-frequency co-occurrence community. S204. Rank the high-frequency co-occurrence communities according to their comprehensive weights, determine the high-frequency co-occurrence communities to be trained first based on the ranking results, and train each high-frequency co-occurrence community to generate the corresponding LoRA plugin. S205. Generate question information using the knowledge fragment set and the user question; and locate the corresponding LoRA plugin set according to the knowledge fragment set, generate plugin set information by generating plugin set information by combining the plugin information and weight information of each LoRA plugin in the LoRA plugin set; generate a question using the question information and plugin set information, and send the question to the LLM cluster. S206. Using the load balancing server in the LLM cluster, based on the plugin set information in the query, the query is routed to the target LLM, which is the LLM with the most matching plugins in the loaded plugin set information. If the LLM still has plugins from the plugin set information that have not been loaded, the LLM is driven to dynamically load these plugins. S207. The target LLM dynamically adjusts the weights of the plugins based on the weight information in the plugin set information in the question, and adjusts the weights of irrelevant plugins to 0; the target LLM performs reasoning with the support of the relevant plugins to generate an answer to be output to the user.

[0051] Example 3: See Figure 3This embodiment provides an information processing method including steps 1 to 15. Steps 1 to 13 involve reasoning and answering related processing flows, executed through the cooperation of various components. Specifically, the RAG component obtains raw knowledge fragments by calling a vector database and outputs them to a plugin matcher. It then queries GraphRAG to obtain document region identifiers and further queries the plugin mapping table in the plugin metadata database (including the mapping relationship between knowledge fragments and document regions, and the mapping relationship between document regions and LoRA plugins) to obtain candidate LoRA plugin information. A target plugin set (i.e., a LoRA plugin information set) is generated and output to a load balancer. The load balancer determines the target LLM node and routes the query request to it. The query request includes the user's question, the retrieved knowledge fragment set related to the question, and the LoRA plugin information set. Finally, the target LLM node generates a corresponding answer based on the query request and returns it to the user.

[0052] Steps 14 and 15 involve fine-tuning the training process, which is executed through the cooperation of various components used for dynamic LoRA fine-tuning. Specifically, LLM constructs or updates a document fragment co-occurrence graph based on knowledge fragments; the LoRA training component detects high-frequency co-occurrence communities based on the document fragment co-occurrence graph constructed or updated by LLM according to preset rules; a training document set is generated based on the high-frequency co-occurrence communities; and LoRA plugin training is performed based on the training document set.

[0053] For further details regarding the training process described above, please refer to [link / reference]. Figure 4 For example, see below.

[0054] In some implementations, high-frequency co-occurrence community analysis is performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community, including: The co-occurrence relationship graph of document fragments is constructed or updated using the co-occurrence relationship graph; According to preset rules, high-frequency co-occurrence communities are detected for the co-occurrence relationship graph of the document fragments.

[0055] In some implementations, the document fragment co-occurrence graph includes multiple nodes, each node being a document fragment. The granularity of these document fragments as nodes can be flexibly set: it can be specified as an Nth-level chapter granularity or refined to a paragraph granularity, depending on the overall size of the knowledge base and actual analysis needs. This approach effectively controls the node size while ensuring the accuracy of knowledge correlation, thus improving the efficiency of constructing and applying the co-occurrence network (i.e., the document fragment co-occurrence graph).

[0056] Therefore, constructing the co-occurrence graph of the document fragments includes: The RAG component outputs at least one knowledge fragment related to the question raised by the user (hereinafter referred to as the question); Determine the document segment corresponding to each of the aforementioned knowledge segments; Based on document fragments that have co-occurrence relationships, a document fragment co-occurrence relationship graph is determined, where the nodes of the document fragment co-occurrence relationship graph are document fragments, and the edges between nodes indicate that there is a co-occurrence relationship between document fragments.

[0057] In some implementations, constructing the co-occurrence graph of the document fragments further includes determining the weights of edges between nodes in the following manner: For every two nodes, the number of times the document fragments of these two nodes co-occur is determined as the base weight; based on the base weight and the time decay factor (e.g., multiplying the base weight and the time decay factor), the weight of the edge between these two nodes is determined.

[0058] In some implementations, the time decay factor is a value that is dynamically adjusted based on the interval between the co-occurrence time of the document fragments of the two nodes and the current time.

[0059] For example, the co-occurrence decay factor is set to 1.0 for the past 7 days, 0.7 for 8-30 days, 0.4 for 31-90 days, and 0.1 for more than 90 days. This rule ensures that the weighting of co-occurrence relationships across different time dimensions is reasonable, highlighting the relevance of recent knowledge while not completely ignoring the value of historically high-frequency associations.

[0060] In some implementations, updating the document fragment co-occurrence graph includes: For each knowledge fragment, locate the corresponding document fragment based on the position of the knowledge fragment in the document; For each document fragment located, check whether the document fragment already exists in the document fragment co-occurrence graph; if it does not exist, add a node for the document fragment in the document fragment co-occurrence graph and initialize the attribute information of the document fragment (e.g., including unique identifier, source document unique identifier, location information, text content hash value, occurrence count, etc.); if it already exists, update the attribute information of the document fragment (e.g., update the occurrence count). For any pair of all located document fragments, if there is no co-occurrence edge in the document fragment co-occurrence graph, a new edge is created and its weight is initialized; if a co-occurrence edge already exists, the attribute information of the co-occurrence edge (e.g., including the number of co-occurrences and the co-occurrence timestamp) is updated according to the current co-occurrence behavior.

[0061] In some implementations, the preset rules include one or a combination of the following rules: According to a preset period, high-frequency co-occurrence communities are periodically detected for the co-occurrence relationship graph of the document fragments; When the number of newly added nodes in the document fragment co-occurrence graph exceeds a preset threshold, high-frequency co-occurrence communities are detected for the document fragment co-occurrence graph.

[0062] In some implementations, for the co-occurrence graph of the document fragments, high-frequency co-occurrence communities are detected, including: The document fragment co-occurrence graph was divided into high-frequency co-occurrence communities using the Leiden algorithm, resulting in at least one high-frequency co-occurrence community. Determine the overall weight of each of the aforementioned high-frequency co-occurrence communities.

[0063] In some implementations, determining the overall weight of each of the high-frequency co-occurrence communities includes: For each of the aforementioned high-frequency co-occurrence communities, a weighted sum is performed based on one or a combination of the following parameters of the high-frequency co-occurrence community to obtain the comprehensive weight of the high-frequency co-occurrence community: This includes the total number of occurrences of all nodes within the high-frequency co-occurrence community, the total weight of edges, and the average retrieval ranking of document fragments.

[0064] Therefore, the embodiments of this application can further ensure that LoRA prioritizes knowledge co-occurrence communities in a way that is both scientific and reasonable.

[0065] In some implementations, a target high-frequency co-occurrence community is selected from at least one high-frequency co-occurrence community for training to generate a LoRA plugin corresponding to the target high-frequency co-occurrence community, including: Select the high-frequency co-occurrence community with the highest overall weight (i.e., the high-priority high-frequency co-occurrence community) from at least one high-frequency co-occurrence community as the target high-frequency co-occurrence community; For each document involved in the target high-frequency co-occurrence community, determine the set of document fragments of that document in the target high-frequency co-occurrence community, extract the training content from the set of document fragments through the GraphRAG knowledge graph of that document, and generate the training document based on the extracted training content and the structure of the document. A training document set is generated using the training documents of each document involved in the target high-frequency co-occurrence community; The document set to be trained is input into LoRA, and the LoRA plugin is obtained through LoRA training.

[0066] In some implementations, for each document involved in a target high-frequency co-occurrence community, training content is extracted from the document fragment set using the document's GraphRAG knowledge graph. Based on the extracted training content and the document's structure, a training document is generated, including: For each document (target document) involved in the target high-frequency co-occurrence community: The target document is preprocessed using GraphRAG (Graph-Based Retrieval-Augmented Generation). Based on the preprocessed target document, a GraphRAG knowledge graph is generated, wherein the GraphRAG knowledge graph includes multiple text blocks obtained by segmenting the target document; For each document fragment in the document fragment set, locate the corresponding text block in the GraphRAG knowledge graph, and obtain the GraphRAG semantic community to which the text block belongs based on the entities and relationships associated with the text block; The text blocks corresponding to all entities and relations contained in each GraphRAG semantic community are included in the set of text blocks to be trained; For each text block in the set of text blocks to be trained, expand to the text blocks adjacent to it before and after the text block to form an expansion unit; For the target document that has undergone the preprocessing, its hierarchical structure and the content of each expansion unit are preserved. For the document area outside each expansion unit, a preset tag is used for replacement, and finally the training document corresponding to the target document is formed.

[0067] Among them, a set of document fragments belonging to the same target document (also called a set of document fragments) is, for example, Figure 4 The fragments shown are categorized to obtain multiple sets of fragments belonging to the same document. Each set of fragments includes multiple document fragments belonging to the same document.

[0068] The preprocessing includes, for example, converting the target document into a format with hierarchical information to ensure that GraphRAG can recognize its native hierarchical structure, such as chapters, sections, and paragraphs.

[0069] Based on this, GraphRAG no longer uses the conventional fixed-word text block division method during the indexing stage. Instead, it splits the corresponding hierarchical text blocks according to the inherent chapter-section-paragraph hierarchical structure of the document, and records the parent-child relationship between text blocks through chunk_include_chunk edges, ultimately forming a clear document structure tree - this structure can intuitively present the hierarchical relationship of knowledge units.

[0070] The GraphRAG, based on traditional RAG, introduces knowledge graph technology to break down documents into text blocks and construct an entity relationship network to form a knowledge graph, supporting accurate retrieval and knowledge tracing based on entity associations. In this embodiment, the device relies on GraphRAG to realize document hierarchical mapping, entity relationship association, and semantic community division, providing knowledge association-level support for the generation of training documents and ensuring the logical coherence of training data.

[0071] Further as Figure 4 As shown, for each document fragment in the document fragment set, the corresponding text block in the GraphRAG knowledge graph is located, and based on the entities and relationships associated with that text block, the GraphRAG semantic community to which that text block belongs (i.e., Figure 4 (The graph semantic community shown). The text blocks corresponding to all entities and relations contained in each GraphRAG semantic community are included in the set of text blocks to be trained; For each text block in the set of text blocks to be trained, expand to the text blocks adjacent to it before and after the text block to form an expansion unit; For the target document that has undergone the preprocessing, its hierarchical structure and the content of each expansion unit are preserved. For the document area outside each expansion unit, a preset mark is used for replacement, and finally the training document corresponding to the target document is formed. The training documents corresponding to each target document are collected to form a training document set.

[0072] The GraphRAG semantic community is a semantic unit based on the semantic associations between entities. GraphRAG semantic communities are formed through hierarchical clustering and have multiple community levels; this section focuses on the middle-level communities.

[0073] In some implementations, a GraphRAG knowledge graph is generated based on the preprocessed target document, including: The preprocessed target document is then divided into multiple text blocks according to its hierarchical structure. The LLM (Large Language Model) is called to process each text block, identify the entities within it, extract the relationships between entities, obtain entity and relationship instances, and use the entity and relationship instances to initially construct the GraphRAG knowledge graph; The entities in the GraphRAG knowledge graph are grouped, and each group forms a semantic community. Generate a summary for each of the semantic communities; The text blocks and entities in the knowledge graph are converted into vectors and stored in the vector database (i.e., the vector database in the retrieval module). The GraphRAG knowledge graph containing the structured data of the entities, relationships, and semantic communities will be persistently stored (e.g., stored in GraphRAG).

[0074] After the training document set corresponding to the high-frequency co-occurrence community is generated, the LoRA fine-tuning process (i.e., LoRA plugin training) can be started to internalize the knowledge of the high-frequency co-occurrence community into the model parameters.

[0075] like Figure 4 As shown, the LoRA training component takes the document set to be trained as input, trains the LoRA plugin through the LoRA training component, and outputs the trained LoRA plugin. The association between LoRA plugins and metadata information is stored (e.g., it can be stored in a plugin metadata database), wherein the metadata information includes the set of document regions corresponding to the LoRA plugin.

[0076] In other words, in this embodiment, after each high-frequency co-occurrence community is trained, an independent LoRA plugin is generated (meaning there is a one-to-one correspondence between high-frequency co-occurrence communities and LoRA plugins), and the LoRA plugins are stored with complete metadata information. In this embodiment, each high-frequency co-occurrence community corresponds to an independent LoRA plugin, and the LoRA plugins support dynamic loading, unloading, and incremental training, serving as a key carrier for knowledge internalization.

[0077] The metadata information includes, for example, the document region set corresponding to the LoRA plugin, community identifier, training time, applicable model version, and training parameter configuration. This metadata information is not only used for subsequent LoRA plugin matching and management, but also provides a basis for LoRA plugin compatibility evaluation during model upgrades, ensuring the portability of LoRA plugins across different model versions. Specifically, the LoRA plugin is stored in association with a document region set, realizing a mapping between LoRA plugins and document regions. When a new query triggers RAG retrieval of relevant document fragments, the corresponding LoRA plugin information set can be quickly matched. In other words, this embodiment of the application implements a mapping between LoRA plugins and document regions, allowing for rapid matching of the corresponding LoRA plugin information set when a new query initiated by a user triggers RAG retrieval of relevant document fragments.

[0078] The following further combines the appendix Figure 5 Provide examples to illustrate the processing procedures related to reasoning and question answering.

[0079] Example 4: In some implementations, the corresponding LoRA plugin set is located based on the knowledge fragment set, and the plugin set information of the LoRA plugin set is determined, including: For each knowledge fragment in the knowledge fragment set, the corresponding document region is located based on the document and location information of the knowledge fragment, and the LoRA plugin corresponding to the knowledge fragment is determined based on the mapping relationship between the document region and the LoRA plugin. Using the LoRA plugins corresponding to each knowledge fragment in the knowledge fragment set, a LoRA plugin set is generated; By using the plugin information and weight information of each LoRA plugin in the LoRA plugin set, the plugin set information of the LoRA plugin set is generated.

[0080] For example Figure 5 As shown, when a user asks a question, steps S401 to S403 are executed. The RAG component performs a retrieval and returns relevant knowledge fragments to support real-time reasoning. Then, based on the retrieved fragments, the corresponding LoRA plugin in the plugin library is matched.

[0081] In some implementations, the mapping relationship between the document region and the LoRA plugin is maintained through an inverted index of the LoRA plugin and the document region, where the document region identifier is the key and the LoRA plugin identifier is the value.

[0082] Thus, the inverted index can improve matching efficiency and support millisecond-level LoRA plugin query operations.

[0083] In some implementations, the query is routed to the target LLM based on the plugin set information in the query via a load balancer in the LLM cluster, including: By using the load balancing server in the LLM cluster, based on the LoRA plugin loading status and load of each LLM node, it is determined whether there is a target LLM node that has loaded all the required LoRA plugins that match the plugin set information and whose load is lower than a preset threshold. If it exists, the query will be routed to the target LLM; If none exists, the LLM with the most loaded plugins matching the plugin set information is identified as the target LLM, and a LoRA plugin loading instruction is sent to the target LLM node to instruct it to load the plugins not loaded in the plugin set information. After the target LLM node has completed loading all the required LoRA plugins matching the plugin set information, the query is routed to the target LLM.

[0084] The target LLM node generates the corresponding answer and provides feedback to the user.

[0085] LLM is an artificial intelligence model pre-trained on massive amounts of text data, possessing powerful natural language understanding and generation capabilities. It is the core foundational model for completing inference responses in the device provided in this application embodiment. The device dynamically routes user queries to suitable LLM nodes and loads corresponding LoRA plugins to improve the model's inference accuracy in specific domains.

[0086] For example Figure 5 In steps S404 to S406, the load balancer (also known as the load balancing server) analyzes the status of the LLM nodes. If there is a node that has loaded the required plugin and meets the load requirements, the query request is directly routed to that node. If there is no matching node, the node with the most matching nodes is selected, the plugin is loaded, and the query request is routed to that node.

[0087] Therefore, the routing strategy for query requests in this embodiment of the application takes into account both service response speed and resource utilization, ensuring that query requests can be quickly allocated to appropriate LLM nodes.

[0088] In some implementations, the LoRA plugin is loaded into the target LLM to perform reasoning on the question and generate an answer to be output to the user, including: For each LoRA plugin in the plugin set information, the influence coefficient of the LoRA plugin is set according to the weight information of the LoRA plugin; wherein, the higher the weight of the LoRA plugin, the greater the influence coefficient. Based on the influence coefficient of each LoRA plugin in the plugin set information, answer content is generated for output to the user, wherein the larger the influence coefficient of a LoRA plugin, the greater the influence of the LoRA plugin on the answer content.

[0089] In some implementations, the weight information of the LoRA plugin is determined in the following way: For high-frequency co-occurrence communities that directly match the question, the corresponding LoRA plugin weight is positively correlated with the number of knowledge fragments matched by the high-frequency co-occurrence community in this RAG search. The more knowledge fragments matched, the higher the corresponding plugin weight. For high-frequency co-occurrence communities that do not directly match the question, the LoRA plugin weight corresponding to the high-frequency co-occurrence community that does not directly match is calculated by combining the plugin weight of the matched high-frequency co-occurrence communities and the total correlation between the high-frequency co-occurrence communities that do not directly match and the matched high-frequency co-occurrence communities. The total correlation is determined by summarizing the correlation between each high-frequency co-occurrence community that is periodically maintained. If the total correlation between a non-directly matched high-frequency co-occurrence community and a matched high-frequency co-occurrence community is lower than a preset threshold, the weight of the LoRA plugin corresponding to the non-directly matched high-frequency co-occurrence community is set to 0.

[0090] For example Figure 5 In steps S407-S408, the LLM node adjusts the plugin weights as described above, with the weights of irrelevant plugins being reset to zero. Finally, the LLM, combined with the loaded LoRA plugins, generates accurate answers to reply to users.

[0091] Therefore, the embodiments of this application can further avoid retrieval interference caused by calling too many low-association LoRA plugins.

[0092] in addition, Figure 5 The above shows the overall processing flow provided by the embodiment of this application, wherein steps S409 to S417 involve the above-mentioned training process.

[0093] Step S409 takes the search results and adds the newly searched fragments to the LLM, triggering the dynamic evolution of the community. Then, in step S410, when the incremental fine-tuning threshold is reached, a new round of LoRA incremental training is started. Finally, the trained LoRA plugins are updated to the plugin library to realize the plugin library update iteration (i.e., step S417).

[0094] Step S411 follows the retrieval results from step S401, executing steps S411 to S416, namely: obtaining the latest knowledge fragments retrieved by the RAG component and simultaneously inputting these knowledge fragments into the LLM to construct or update the co-occurrence relationship graph; identifying high-frequency co-occurrence communities using the Leiden algorithm, then integrating knowledge units based on GraphRAG to generate a training document set that retains its original logical structure, and subsequently performing LoRA dynamic fine-tuning training to generate LoRA plugins. Finally, updating the generated LoRA plugins to the plugin library achieves plugin library update iteration (i.e., step S417).

[0095] In summary, the technical solution provided in this application is divided into stages, and detailed examples are given for each stage. For instance, the device in this application achieves efficient internalization and accurate retrieval of domain knowledge through six core processing stages, with each stage working collaboratively to form a complete closed loop. The implementation methods of each stage are illustrated below: Phase (1): Constructing a co-occurrence graph of document fragments: The core task of constructing a document fragment co-occurrence relationship graph is to mine the correlations from the retrieval fragments accumulated during user interactions and build a dynamically updated co-occurrence relationship network.

[0096] When a user submits a query to the device, the RAG component returns a series of knowledge fragments related to the user's question. These knowledge fragments may come from different documents. The device finds the corresponding document fragments based on the position of the knowledge fragments in the documents, considers document fragments whose content appears in the same search result as having a co-occurrence relationship, and updates the global document fragment co-occurrence relationship graph (or simply co-occurrence relationship graph) accordingly.

[0097] In some implementations, each document fragment serves as a node in the co-occurrence graph, containing attributes such as a unique identifier, a source document unique identifier, location information, text content hash, and frequency of occurrence. Edges between nodes represent co-occurrence relationships, and their weights are calculated using a time decay model. The base weight is the number of times two document fragments co-occur. This base weight is further combined with a time decay factor (e.g., the base weight multiplied by the time decay factor) to ultimately calculate the weight of the edge between nodes. The time decay factor is dynamically adjusted based on the interval between the co-occurrence time and the current time, with more recent co-occurrence relationships receiving higher weights to ensure the timeliness of community analysis. In some implementations, the time decay factor follows a step-wise rule, for example: a decay factor of 1.0 for co-occurrence relationships within the last 7 days, 0.7 for 8-30 days, 0.4 for 31-90 days, and 0.1 for over 90 days. This rule ensures that the weight differences for co-occurrence relationships across different time dimensions are reasonable, highlighting the relevance of recent knowledge while not completely ignoring the value of historically high-frequency associations.

[0098] The core reason for not directly using knowledge fragments as nodes in the co-occurrence graph is that knowledge fragments are typically fine-grained and numerous, and directly using them as nodes would easily lead to a surge in the number of nodes in the graph structure. This would not only significantly increase the resource consumption of graph computation but also potentially reduce the efficiency of subsequent community partitioning and association analysis due to node redundancy. Document fragments, on the other hand, allow for flexible granularity settings: they can be specified at the Nth-level chapter level or refined to the paragraph level, depending on the overall size of the knowledge base and actual analysis needs. This approach can effectively control the node size while ensuring the accuracy of knowledge association, thus improving the efficiency of constructing and applying the co-occurrence network.

[0099] In some implementations, to ensure the dynamism and accuracy of the co-occurrence graph, the device establishes a real-time update mechanism. For example, each time the RAG component completes a retrieval for a user's question and returns a set of knowledge fragments (i.e., retrieval results), the device can first locate the corresponding document fragment based on the location of the knowledge fragment in the document. For the located document fragment, it first checks whether it already exists in the co-occurrence graph. If it does not exist, a node for the document fragment is added to the co-occurrence graph, and its unique identifier, source document unique identifier, location information, text content hash, and occurrence count are initialized. If it already exists, its occurrence count attribute is updated. After completing the node check and processing, the co-occurrence graph detection process is automatically triggered, performing pairwise matching on all located document fragments. If no co-occurrence edge exists, a new edge is created and its weight is initialized. If a co-occurrence edge already exists, the co-occurrence count and co-occurrence timestamp of the edge are updated based on this co-occurrence behavior.

[0100] The co-occurrence edge refers to the edge between nodes of document fragments that have a co-occurrence relationship. In other words, if two document fragments have a co-occurrence relationship, then there will be an edge between the nodes of these two document fragments in the co-occurrence relationship graph, and this edge is the co-occurrence edge.

[0101] Phase (II) Identification and Prioritization of High-Frequency Co-occurrence Communities: As the co-occurrence relationship graph continues to expand, the device will initiate a high-frequency co-occurrence community (hereinafter referred to as community) detection process according to preset rules. The triggering conditions include timed triggering (i.e., periodically executing high-frequency co-occurrence community detection) and quantitative triggering (i.e., executing high-frequency co-occurrence community detection when the number of nodes of newly added document fragments exceeds a threshold) to ensure that the community division can reflect the latest changes in knowledge association in a timely manner.

[0102] For example, the Leiden algorithm can be used to partition co-occurrence graphs into communities. This algorithm maximizes the modularity index through multiple rounds of local optimization and community aggregation operations, achieving a partitioning effect where nodes within a community are highly interconnected, while nodes between communities are less interconnected. Furthermore, the Leiden algorithm supports adjusting the community granularity through a resolution parameter. In various domain applications, an appropriate resolution parameter can be set based on the complexity of domain knowledge and the association density of knowledge units to balance community size and knowledge focus, avoiding overly large communities leading to knowledge contamination and overly small communities causing fragmented connections. The Leiden algorithm is an efficient algorithm for detecting community structure in large networks, aiming to identify tightly connected node groups (communities) from complex networks—communities with dense connections within each community and sparse connections between communities.

[0103] The Leiden algorithm was chosen based on its three core advantages: First, the resolution is adjustable. The resolution parameter (i.e., the resolution parameter) can be used to precisely control the community granularity. The larger the parameter value, the more refined the community division. It can effectively detect clusters of small knowledge units that co-occur frequently, overcome the defect of the Louvain algorithm being insensitive to small communities, and adapt to the differentiated density of knowledge associations in different fields. Secondly, the results are highly stable. By optimizing the local movement rules, the impact of the initial node traversal order on the partitioning results is reduced. Multiple runs can yield a more consistent community structure, avoiding deviations in the knowledge scope of subsequent LoRA training due to result fluctuations. Third, it is highly efficient, with a time complexity close to O(nlogn) (where n is the number of nodes). Even if the number of nodes in the co-occurrence relationship graph reaches millions, it can still quickly complete the community division and meet the timeliness requirements for dynamic updates of high-frequency co-occurrence communities.

[0104] After the communities are divided, the device calculates the overall weight of each community. The overall weight of the community serves as the priority for subsequent LoRA training and directly affects the allocation order of training resources.

[0105] The calculation of the community's overall weight covers three core dimensions: First, the total number of times all nodes appear within the community reflects the level of attention that community knowledge receives from user queries. Second, the total weight of the community's boundaries reflects the closeness of the connections between knowledge units within the community; Third, the average search ranking of document fragments in the community. The higher the ranking, the higher the degree of matching between the community's knowledge and users' needs.

[0106] In some implementations, the weight values ​​of the above three dimensions can be normalized and then weighted and summed according to preset weight coefficients (the specific values ​​are determined according to actual needs, and are not limited in this application embodiment) to obtain the final comprehensive weight of each community, so as to ensure that the priority ranking of LoRA when training each knowledge co-occurrence community is both scientific and reasonable.

[0107] Phase (III) Generation of the training document set: For the highest-priority (i.e., highest overall weight) frequently co-occurring communities, the device extracts relevant content from each original document to generate a structurally complete set of documents to be trained. This process relies on the entity relationship network built by GraphRAG to achieve accurate content integration, ensuring that the documents to be trained not only cover the core knowledge of the community but also retain the logical coherence of the knowledge. Specifically, it includes the following steps one and two: Step 1: For each target document, see [link / reference] Figure 6 Perform the following operations: S501. Preprocess the target document using GraphRAG.

[0108] (For example, converting the target document into a format with hierarchical information to facilitate the generation of GraphRAG knowledge graphs)

[0109] S502. Based on the preprocessed target document, generate a GraphRAG knowledge graph (hereinafter referred to as the knowledge graph), wherein the GraphRAG knowledge graph includes multiple text blocks obtained by segmenting the target document.

[0110] In other words, the preprocessed document will then undergo the GraphRAG indexing phase. This GraphRAG indexing process transforms the document from text into a knowledge graph. See details... Figure 7 The GraphRAG indexing phase includes the following steps: S601, Text Segmentation: The target document is divided into text blocks (or text units). The division methods include fixed-size splitting, structural splitting, semantic splitting, and recursive splitting.

[0111] S602, Entity Relationship Extraction: The LLM is called to process each text block, identify the entities within it, extract the relationships between the entities, and then use these identified entity and relationship instances to initially construct a knowledge graph; S603, Semantic Community Clustering: The Leiden algorithm is used to group entities in the knowledge graph, aggregating closely related entities to form semantic communities, thereby achieving structured classification of entities.

[0112] S604, Community Summary Generation: Automatically generate summaries for each aggregated semantic community, that is, extract the core entities, key relationships and core information within the semantic community, to achieve a high-level summary of the semantic community content.

[0113] S605, Vector Embedding: The entities in the text blocks and knowledge graphs are converted into vectors and stored in a vector database (such as LanceDB) to support fast similarity search in the subsequent query stage (i.e., retrieval stage).

[0114] S606, Persistent Storage: For example, the completed knowledge graph containing structured data such as entities, relationships, and semantic communities can be saved in Parquet file format to ensure that the data can be retained for a long time and supported for subsequent query stages (i.e., retrieval stages).

[0115] S503. Determine the set of document fragments belonging to the target document in the high-frequency co-occurrence community with the highest comprehensive weight.

[0116] S504. For each document fragment in the document fragment set, locate the corresponding text chunk in the GraphRAG knowledge graph, and obtain the GraphRAG semantic community to which the text chunk belongs based on the entities and relationships associated with the text chunk.

[0117] S505. Include all text blocks corresponding to entities and relations contained in each GraphRAG semantic community into the text block set to be trained in this document.

[0118] Text blocks in the same set of text blocks to be trained may be distributed in different chapters of a document fragment, and may be relatively concentrated in some areas, all revolving around the same core semantic theme.

[0119] S506. For each text block in the set of text blocks to be trained, expand it to the text blocks adjacent to it before and after to form an expansion unit.

[0120] In order to ensure the contextual coherence of knowledge, each text block in this application is extended to the text blocks before and after it. The number of extensions is set according to the semantic integrity requirements of the text blocks, forming extension units.

[0121] The purpose of extended processing is to supplement the preceding and following information of text blocks, avoid the knowledge logic break caused by isolated extraction of text blocks, and ensure that the knowledge units in the training data have complete semantic context.

[0122] S507. For the target document that has undergone the preprocessing, retain its hierarchical structure and the content of each extended unit. For the document area outside each extended unit, use a preset mark to replace it (use a uniform mark to omit and replace it), and finally form the training document corresponding to the target document.

[0123] This reduces the interference of redundant information on training while maintaining the inherent logical framework of the document, helping the model to better understand the organizational relationships of knowledge.

[0124] Step 2: If the document fragments in the high-frequency co-occurrence community come from multiple target documents, the device will perform the above processing on each target document separately to generate multiple training documents (e.g., Figure 4 As shown in the figure, these documents to be trained together constitute the training dataset (i.e., the set of documents to be trained) for this community. That is, the training documents corresponding to each target document are collected to form the set of documents to be trained.

[0125] Each training document corresponds to an original document, ensuring that the knowledge logic of different documents is not confused with each other. At the same time, by incorporating the content of multiple documents into the training data, LoRA's understanding of cross-document related knowledge is deepened.

[0126] Phase (IV) LoRA Dynamic Training and LoRA Plugin Management: The LoRA plugin training process requires optimizing parameter configurations based on hardware environment characteristics to achieve a balance between training efficiency and effectiveness. Parameter configurations need targeted adjustments for different graphics card specifications. For example, on high-performance graphics cards, the batch size can be increased to improve training speed, while the number of training epochs should be set appropriately and dynamically adjusted according to the amount of text to ensure the model can fully learn community knowledge without overfitting. The rank of the low-rank matrix (Rank) is the dimensional parameter of the low-rank matrix in LoRA technology, significantly affecting the LoRA plugin's freedom and expressiveness in adjusting model parameters. Rank and Alpha values ​​are also set according to the complexity of domain knowledge. The rank value needs to be set according to the complexity of domain knowledge; too small a rank value may prevent the model from fully learning knowledge details, while too large a rank value will increase training costs. Alpha and rank values ​​are adjusted together to ensure the expressiveness of the low-rank matrix.

[0127] In some implementations, for scenarios involving dynamic knowledge expansion, the device supports incremental training of high-frequency co-occurrence communities. Since a single high-frequency co-occurrence community contains multiple documents (each document only includes training content related to the community's knowledge), community incremental training is further broken down into document incremental training. Specific training strategies are categorized based on document type (existing documents / new documents) and the proportion of newly added content in existing documents, for example, into the following three execution modes: Mode 1: The proportion of newly added content in an existing document is low (e.g., configured to not exceed 30% of the original text): The existing LoRA plugin corresponding to the high-frequency co-occurrence community to which the document belongs is loaded as the initial parameters, and the knowledge parameters already learned in the LoRA plugin are reused to preserve contextual relevance. The training scope covers the entire document to be trained, including the newly added content, but a fine-tuning strategy of low learning rate and few epochs is adopted. For example, the learning rate is reduced to 1 / 3 to 1 / 2 of the initial training (5e-5 to 1e-4), the number of training epochs is reduced to 1 / 3 to 1 / 2 of the initial number, and the sampling weight of the newly added content is increased (for example, the sampling ratio of old content to new content is set to 3:1 or 2:1), which both supplements the new knowledge and minimizes the catastrophic forgetting of existing knowledge.

[0128] Mode 2: The proportion of newly added content in an existing document is too large (e.g., configured to exceed 30% of the original text): If a significant change is detected in the core knowledge of a document, a full retraining is triggered. The training scope remains the entire document to be trained, including the newly added content. The training parameters (e.g., learning rate from 1e-4 to 3e-4, rank value from 8 to 16, optimizer AdamW+ cosine scheduling, etc.) remain consistent with the initial training to ensure that the model can fully learn the correlation logic between the new knowledge and the original knowledge, and to avoid knowledge gaps caused by incremental fine-tuning.

[0129] Mode 3, New Document: The training scope is directly included in the content of the new document that is related to the knowledge of the high-frequency co-occurrence community. The training parameters are configured in the same way as the document parameters of the initial training of the community (e.g., the Rank value is set according to the task type, the Warmup ratio is 5% to 10%, etc.). Through targeted training, the knowledge of the new document is associated with the existing knowledge in the high-frequency co-occurrence community.

[0130] Incremental training for high-frequency co-occurrence communities is categorized by training parameters. Documents using the same parameters are merged for incremental training, while different parameters correspond to different training methods. During incremental training, the device records multi-dimensional training logs in real time, including training loss change curves, dynamic learning rate adjustment records, details of new content sampling ratios, and regularization parameter (Dropout / weight decay) adaptation information. This provides data support for subsequent analysis of training effects and optimization of parameter strategies, and also provides a basis for the high-frequency co-occurrence community analysis.

[0131] During LLM upgrades, the device first assesses the compatibility between the new and old LLMs. The assessment dimensions include consistency of the underlying architecture, consistency of the pre-training base, and LoRA adaptation methods. If the new and old LLMs have the same architecture and the same pre-training weight base, the existing LoRA plugin is directly reused. If the architectures differ significantly, the co-occurrence relationship communities are reorganized and redefined based on the existing co-occurrence relationship graph, and the LoRA plugin is trained according to the new LLM specifications. The training of the new LLM and the operation of the old LLM can be parallelized. Before the new LoRA plugin is fully trained, the original LLM and the original LoRA plugin continue to provide services, ensuring service continuity and avoiding service interruptions due to LLM upgrades.

[0132] Phase (5): Search and LoRA Plugin Matching When a user initiates a new query, the device first retrieves relevant knowledge fragments through the RAG component, and then, based on the pre-built dual mapping relationship between knowledge fragments and document regions, and between document regions and LoRA plugins, locates the corresponding LoRA plugin based on these knowledge fragments, thereby obtaining accurate information about the relevant LoRA plugin set (i.e., the information about the LoRA plugin set corresponding to the question initiated by the user, such as the metadata information of each LoRA plugin in the LoRA plugin set).

[0133] In some implementations, during the LoRA plugin matching process (implemented via a plugin matcher), the device calculates the weight of a LoRA plugin based on the number of matching fragments it contains (i.e., document fragments that match the LoRA plugin). For example, the weight value is positively correlated with the number of matching fragments a LoRA plugin contains; the more matching fragments a LoRA plugin contains, the higher its relevance to the current query, and the larger its weight value.

[0134] In some implementations, for document fragments across communities, multiple LoRA plugins from different communities may be matched. In this case, all of these LoRA plugins are included in the relevant LoRA plugin information set.

[0135] To improve matching efficiency, in some implementations, the device maintains an inverted index of LoRA plugins and document regions, with the document region identifier as the key and the LoRA plugin identifier as the value, supporting millisecond-level LoRA plugin query operations.

[0136] In some implementations, the device periodically checks the validity of LoRA plugins and cleans up invalid LoRA plugins to address situations such as deleted documents, corrupted LoRA plugin files, or outdated applicable model versions. This avoids interference from invalid LoRA plugins with the matching results and ensures the accuracy and efficiency of LoRA plugin matching.

[0137] For newly generated LoRA plugins, the device updates the inverted index of the LoRA plugin and the document area, as well as the mapping relationship between the LoRA plugin and the document area in real time, to ensure that the new LoRA plugin can participate in the matching process in a timely manner and provide support for user Q&A.

[0138] Phase (VI), Dynamic Routing and Weight Adjustment: The device sends the user's question, the set of knowledge fragments retrieved by the RAG component, and the matching set of weighted LoRA plugin information to the load balancer of the LLM cluster. The load balancer of the LLM cluster performs dynamic routing and LoRA plugin scheduling. The routing strategy takes into account both service response speed and resource utilization, ensuring that query requests can be quickly distributed to the appropriate LLM nodes.

[0139] In some implementations, the routing policy follows two priorities: the LoRA plugin loading status of the LLM node and its load status. Specific policies include: The load balancer checks the LoRA plugin loading status and load of each LLM node to find out if there are any LLM nodes that have loaded all the required LoRA plugins and whose load is below the preset threshold. If such a node exists (as the target LLM node), the query request will be routed directly to that target LLM node. If no such node exists, the node with the most LoRA plugin matches is selected as the target LLM node. A LoRA plugin loading command is sent to this target LLM node. Once the target LLM node has completed loading the LoRA plugin, the query request is routed to it. During the LoRA plugin loading process, the load balancer monitors the loading progress in real time. If loading times out or fails, it automatically switches to other candidate LLM nodes to ensure service availability.

[0140] The query request includes the question raised by the user, the set of knowledge fragments retrieved by the RAG component, and the matching weighted set of LoRA plugin information.

[0141] Upon receiving a query request, the LLM node, at the single-question-answer granularity, sets the influence coefficient of each LoRA plugin based on its weight. For example, it sets a scaling factor parameter and adjusts the weight distribution of LoRA plugins in the rules to ensure that LoRA plugins with higher weights have a greater impact on the model's output answer. Simultaneously, it sets the influence coefficient of LoRA plugins loaded but not matched in the current LLM node to 0, effectively temporarily unloading these irrelevant LoRA plugins to prevent them from interfering with the reasoning process of the current query and ensuring that the model can focus on knowledge relevant to the query.

[0142] At the question-and-answer granularity level, as described in stage (V) above, the calculation of LoRA plugin weights follows these rules: For high-frequency co-occurrence communities that directly match the current query, the weight of their LoRA plugin is positively correlated with the number of knowledge fragments matched by that high-frequency co-occurrence community in this RAG component retrieval. That is, the more knowledge fragments matched, the higher the weight of their LoRA plugin. For high-frequency co-occurrence communities that do not directly match the current query, the weight of their LoRA plugin can be calculated by combining the weights of matched high-frequency co-occurrence communities and the total correlation between the high-frequency co-occurrence community and the set of matched high-frequency co-occurrence communities. The total correlation can be obtained by periodically calculating and summarizing the correlation between each high-frequency co-occurrence community. Considering that there is a certain basic correlation between communities, further, to avoid interference caused by calling too many low-correlation LoRA plugins, if the total correlation between a high-frequency co-occurrence community that does not directly match and the set of matched high-frequency co-occurrence communities is lower than a preset threshold, the weight of the LoRA plugin corresponding to that high-frequency co-occurrence community is automatically set to 0.

[0143] Furthermore, to optimize resource usage, the device implements a dynamic LoRA plugin unloading mechanism: The load balancer records the last access time of each LoRA plugin. If the interval between the last access time and the current time of a LoRA plugin exceeds a preset threshold, the LoRA plugin is determined to be an idle LoRA plugin, and an uninstallation command is sent to the corresponding LLM node. After receiving the uninstallation command, the LLM node executes the LoRA plugin uninstallation process. The uninstallation operation is recorded in the log for easy tracking of LoRA plugin usage later.

[0144] In summary, the information processing apparatus provided in this application takes user queries as the trigger point. While acquiring knowledge fragments to support reasoning through the RAG component, it simultaneously models the co-occurrence relationships of the retrieved fragments and identifies high-frequency co-occurrence communities using the Leiden algorithm. These communities not only match the user's frequently interested areas but also serve as core data units for LoRA fine-tuning, solving the problem of discrepancies between training data selection and actual use. Furthermore, relying on GraphRAG's entity relationship network and document hierarchy mapping, it locates the semantic community to which the entity belongs through associated entities and relationships. Then, it constructs training units through the entity relationships and adjacent extensions contained in the community, generating a training document set that preserves document logic and contextual relationships, providing high-interest, high-value training data for LoRA fine-tuning. In addition, the continuous evolution of knowledge communities drives incremental community fine-tuning.

[0145] Among them, the LoRA plugins generated by fine-tuning are mapped to document regions. When a new query triggers the RAG retrieval of relevant fragments, the corresponding plugin set can be quickly matched. The load balancer server realizes dynamic routing to the adapted LLM node based on the plugin matching and load, while driving the plugin to load in real time and setting the plugin weight according to the message granularity, thus avoiding interference from irrelevant plugins.

[0146] The information processing device provided in this application embodiment achieves full-process automation, ensuring deep internalization of domain knowledge and real-time dynamic adaptation, effectively improving training efficiency, inference accuracy, and dynamic adaptability. Specifically, the beneficial effects achievable by this application embodiment include: (i) Improve LoRA training efficiency. By locating high-frequency co-occurrence communities and organizing core knowledge units, the proportion of invalid training data is significantly reduced, thereby significantly improving training efficiency.

[0147] (ii) Eliminate interference from multiple LoRA plugins. By using a dynamic plugin loading and unloading mechanism and dynamic plugin weight setting, weight dilution and semantic conflicts are avoided, significantly improving the consistency of answers in multi-domain cross-scenarios; millisecond-level weight adjustment response ensures real-time performance and accuracy during concurrent processing.

[0148] (III) Balancing retrieval depth and reasoning efficiency. By integrating fine-tuned knowledge from co-occurrence communities with real-time retrieval fragments, the fragmentation limitations of RAG are avoided, while the efficiency issues of full-text context are resolved, significantly improving the processing speed of complex reasoning tasks, while maintaining logical coherence.

[0149] (iv) Adapting to dynamic knowledge expansion and model iteration. The incremental training strategy significantly shortens the knowledge update response time and effectively improves the adaptability of the device.

[0150] (v) Reduce the cost of manual intervention. Automated co-occurrence community identification and training document generation significantly reduce the workload of manual screening. At the same time, through the dynamic evolution mechanism of the community, the training priority is continuously optimized, reducing the maintenance burden.

[0151] The device provided in this application can be widely used by enterprises and institutions that require domain-specific adaptation of large models, and is especially suitable for knowledge-intensive industries. Furthermore, this device can be used as a foundational capability output to facilitate the rapid construction of domain-specific large model applications, reducing technical barriers and operational costs.

[0152] The following describes the methods and corresponding devices provided in the embodiments of this application. Explanations or examples of the same or corresponding technical features as described above will not be repeated hereafter.

[0153] An electronic device is provided in an embodiment of this application, see [link to example]. Figure 8 For example, including: Processor 600 is used to read the program from memory 620 and execute the following procedures: The user submits a question, which is then input into the search module, which retrieves a set of matching knowledge fragments. For each knowledge fragment in the knowledge fragment set, the corresponding document fragment is located using the knowledge fragment, generating a document fragment set including at least one document fragment; the document fragment set is placed into a co-occurrence graph, and high-frequency co-occurrence community analysis is performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community; a target high-frequency co-occurrence community is selected from the at least one high-frequency co-occurrence community for training, generating a LoRA plugin corresponding to the target high-frequency co-occurrence community; Furthermore, the system generates question information using the knowledge fragment set and the user-submitted question; locates the corresponding LoRA plugin set based on the knowledge fragment set and determines the plugin set information of that LoRA plugin set; generates a question using the question information and the plugin set information, and sends the question to the LLM cluster; through the load balancing server in the LLM cluster, based on the plugin set information in the question, routes the question to the target LLM, loads the LoRA plugin in the target LLM to perform reasoning on the question, and generates answer content to be output to the user.

[0154] In some implementations, high-frequency co-occurrence community analysis is performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community, including: The co-occurrence relationship graph of document fragments is constructed or updated using the co-occurrence relationship graph; According to preset rules, high-frequency co-occurrence communities are detected for the co-occurrence relationship graph of the document fragments.

[0155] In some implementations, the document fragment co-occurrence graph includes multiple nodes, each node being a document fragment; The construction of the document fragment co-occurrence graph includes: The RAG component outputs at least one knowledge fragment related to the question raised by the user. Determine the document segment corresponding to each of the aforementioned knowledge segments; Based on document fragments that have co-occurrence relationships, a document fragment co-occurrence relationship graph is determined, where the nodes of the document fragment co-occurrence relationship graph are document fragments, and the edges between nodes indicate that there is a co-occurrence relationship between document fragments.

[0156] In some implementations, constructing the co-occurrence graph of the document fragments further includes determining the weights of the edges between nodes in the following manner: For every two nodes, the number of times the document fragments of these two nodes co-occur is determined as the basic weight; based on the basic weight and the time decay factor, the weight of the edge between these two nodes is determined.

[0157] In some implementations, the time decay factor is a value that is dynamically adjusted based on the interval between the co-occurrence time of the document fragments of the two nodes and the current time.

[0158] In some implementations, updating the document fragment co-occurrence graph includes: For each knowledge fragment, locate the corresponding document fragment based on the position of the knowledge fragment in the document; For each document fragment located, check whether the document fragment already exists in the document fragment co-occurrence relationship graph; if it does not exist, add a node for the document fragment in the document fragment co-occurrence relationship graph and initialize the attribute information of the document fragment; if it already exists, update the attribute information of the document fragment. For any pairwise relationships between all located document fragments, if there is no co-occurrence edge in the document fragment co-occurrence graph, a new edge is created and its weight is initialized; if a co-occurrence edge already exists, its attribute information is updated based on this co-occurrence behavior.

[0159] In some implementations, the preset rules include one or a combination of the following rules: According to a preset period, high-frequency co-occurrence communities are periodically detected for the co-occurrence relationship graph of the document fragments; When the number of newly added nodes in the document fragment co-occurrence graph exceeds a preset threshold, high-frequency co-occurrence communities are detected for the document fragment co-occurrence graph.

[0160] In some implementations, for the co-occurrence graph of the document fragments, high-frequency co-occurrence communities are detected, including: The document fragment co-occurrence graph was divided into high-frequency co-occurrence communities using the Leiden algorithm, resulting in at least one high-frequency co-occurrence community. Determine the overall weight of each of the aforementioned high-frequency co-occurrence communities.

[0161] In some implementations, determining the overall weight of each of the high-frequency co-occurrence communities includes: For each of the aforementioned high-frequency co-occurrence communities, a weighted sum is performed based on one or a combination of the following parameters of the high-frequency co-occurrence community to obtain the comprehensive weight of the high-frequency co-occurrence community: This includes the total number of occurrences of all nodes within the high-frequency co-occurrence community, the total weight of edges, and the average retrieval ranking of document fragments.

[0162] In some implementations, a target high-frequency co-occurrence community is selected from the at least one high-frequency co-occurrence community for training, generating a LoRA plugin corresponding to the target high-frequency co-occurrence community: Select the high-frequency co-occurrence community with the highest comprehensive weight from the at least one high-frequency co-occurrence community as the target high-frequency co-occurrence community; For each document involved in the target high-frequency co-occurrence community, determine the set of document fragments of that document in the target high-frequency co-occurrence community, extract the training content from the set of document fragments through the GraphRAG knowledge graph of that document, and generate the training document based on the extracted training content and the structure of the document. A training document set is generated using the training documents of each document involved in the target high-frequency co-occurrence community; The document set to be trained is input into LoRA, and the LoRA plugin is obtained through LoRA training.

[0163] In some implementations, for each document involved in a target high-frequency co-occurrence community, training content is extracted from the document fragment set using the document's GraphRAG knowledge graph. Based on the extracted training content and the document's structure, a training document is generated, including: For each document involved in the target high-frequency co-occurrence community: The document was preprocessed using GraphRAG; Based on the preprocessed document, a GraphRAG knowledge graph is generated, wherein the GraphRAG knowledge graph includes multiple text blocks obtained by segmenting the document; For each document fragment in the document fragment set, locate the corresponding text block in the GraphRAG knowledge graph, and obtain the GraphRAG semantic community to which the text block belongs based on the entities and relationships associated with the text block; The text blocks corresponding to all entities and relations contained in each GraphRAG semantic community are included in the set of text blocks to be trained; For each text block in the set of text blocks to be trained, expand to the text blocks adjacent to it before and after the text block to form an expansion unit; For the target document that has undergone the preprocessing, its hierarchical structure and the content of each expansion unit are preserved. For the document area outside each expansion unit, a preset tag is used for replacement, and finally the training document corresponding to the target document is formed.

[0164] In some implementations, a GraphRAG knowledge graph is generated based on the preprocessed documents, including: The preprocessed document is then divided into multiple text blocks according to its hierarchical structure. The LLM is invoked to process each text block, identify the entities within them, extract the relationships between the entities, obtain entity and relationship instances, and use the entity and relationship instances to initially construct the GraphRAG knowledge graph; The entities in the GraphRAG knowledge graph are grouped, and each group forms a semantic community. Generate a summary for each of the semantic communities; The text blocks and entities in the knowledge graph are converted into vectors and stored in a vector database. The GraphRAG knowledge graph, which contains structured data of the entities, relationships, and semantic communities, will be persistently stored.

[0165] In some implementations, the corresponding LoRA plugin set is located based on the knowledge fragment set, and the plugin set information of the LoRA plugin set is determined, including: For each knowledge fragment in the knowledge fragment set, the corresponding document region is located based on the document and location information of the knowledge fragment, and the LoRA plugin corresponding to the knowledge fragment is determined based on the mapping relationship between the document region and the LoRA plugin. Using the LoRA plugins corresponding to each knowledge fragment in the knowledge fragment set, a LoRA plugin set is generated; By using the plugin information and weight information of each LoRA plugin in the LoRA plugin set, the plugin set information of the LoRA plugin set is generated.

[0166] In some implementations, the mapping relationship between the document region and the LoRA plugin is maintained through an inverted index of the LoRA plugin and the document region, where the document region identifier is the key and the LoRA plugin identifier is the value.

[0167] In some implementations, the query is routed to the target LLM based on the plugin set information in the query via a load balancer in the LLM cluster, including: By using the load balancing server in the LLM cluster, based on the LoRA plugin loading status and load of each LLM node, it is determined whether there is a target LLM node that has loaded all the required LoRA plugins that match the plugin set information and whose load is lower than a preset threshold. If it exists, the query will be routed to the target LLM; If none exists, the LLM with the most loaded plugins matching the plugin set information is identified as the target LLM, and a LoRA plugin loading instruction is sent to the target LLM node to instruct it to load the plugins not loaded in the plugin set information. After the target LLM node has completed loading all the required LoRA plugins matching the plugin set information, the query is routed to the target LLM.

[0168] In some implementations, the LoRA plugin is loaded into the target LLM to perform reasoning on the question and generate an answer to be output to the user, including: For each LoRA plugin in the plugin set information, the influence coefficient of the LoRA plugin is set according to the weight information of the LoRA plugin; wherein, the higher the weight of the LoRA plugin, the greater the influence coefficient. Based on the influence coefficient of each LoRA plugin in the plugin set information, answer content is generated for output to the user, wherein the larger the influence coefficient of a LoRA plugin, the greater the influence of the LoRA plugin on the answer content.

[0169] In some implementations, the weight information of the LoRA plugin is determined in the following way: For high-frequency co-occurrence communities that directly match the question, the corresponding LoRA plugin weight is positively correlated with the number of knowledge fragments matched by the high-frequency co-occurrence community in this RAG search. The more knowledge fragments matched, the higher the corresponding plugin weight. For high-frequency co-occurrence communities that do not directly match the question, the LoRA plugin weight corresponding to the high-frequency co-occurrence community that does not directly match is calculated by combining the plugin weight of the matched high-frequency co-occurrence communities and the total correlation between the high-frequency co-occurrence communities that do not directly match and the matched high-frequency co-occurrence communities. The total correlation is determined by summarizing the correlation between each high-frequency co-occurrence community that is periodically maintained. If the total correlation between a non-directly matched high-frequency co-occurrence community and a matched high-frequency co-occurrence community is lower than a preset threshold, the weight of the LoRA plugin corresponding to the non-directly matched high-frequency co-occurrence community is set to 0.

[0170] Transceiver 610 is used to receive and send data under the control of processor 600.

[0171] Among them, Figure 8 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 600 and memory represented by memory 620 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 610 can be multiple components, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium, including wireless channels, wired channels, optical fibers, etc. For different user equipment, the user interface 630 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0172] The processor 600 is responsible for managing the bus architecture and general processing, while the memory 620 can store the data used by the processor 600 when performing operations.

[0173] In some implementations, the processor 600 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a CPLD (Complex Programmable Logic Device), and the processor may also employ a multi-core architecture.

[0174] The processor executes any of the methods described in the embodiments of this application according to the obtained executable instructions by calling a computer program stored in memory. The processor and memory may also be physically separated.

[0175] It should be noted that the device provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0176] See Figure 9 This application provides an information processing apparatus for processing user-submitted questions. The apparatus includes: The knowledge fragment set generation module 901 is used to input the questions submitted by the user into the retrieval module, and retrieve the matching knowledge fragment set through the retrieval module. The fine-tuning training processing module 902 is used to locate the corresponding document fragment for each knowledge fragment in the knowledge fragment set, generate a document fragment set including at least one document fragment; place the document fragment set into a co-occurrence relationship graph, perform high-frequency co-occurrence community analysis on the co-occurrence relationship graph to obtain at least one high-frequency co-occurrence community; select a target high-frequency co-occurrence community from the at least one high-frequency co-occurrence community for training, and generate the LoRA plugin corresponding to the target high-frequency co-occurrence community; The reasoning question-answering processing module 903 is used to generate question information using the knowledge fragment set and the question submitted by the user; and to locate the corresponding LoRA plugin set according to the knowledge fragment set, and determine the plugin set information of the LoRA plugin set; to generate a question using the question information and the plugin set information, and send the question to the LLM cluster; and to route the question to the target LLM through the load balancing server in the LLM cluster based on the plugin set information in the question, and to load the LoRA plugin in the target LLM to reason about the question and generate answer content to be output to the user.

[0177] It should be noted that the division of modules and units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. 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 units described above can be implemented in hardware or as software functional units.

[0178] 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.) or processor 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0179] Any of the devices or apparatuses provided in the embodiments of this application can specifically be desktop computers, portable computers, smartphones, tablet computers, personal digital assistants (PDAs), etc. They may include a central processing unit (CPU), memory, input / output devices, etc. Input devices may include keyboards, mice, touchscreens, etc., and output devices may include display devices such as liquid crystal displays (LCDs) and cathode ray tubes (CRTs).

[0180] The memory may include read-only memory (ROM) and random access memory (RAM), and provides the processor with program instructions and data stored in the memory. In the embodiments of this application, the memory may be used to store the program of any of the methods provided in the embodiments of this application.

[0181] The processor executes any of the methods described in the embodiments of this application according to the program instructions stored in the memory.

[0182] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the methods described in the above embodiments. The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0183] This application provides a computer-readable storage medium for storing computer program instructions used in the apparatus provided in the above-described embodiments, including a program for performing any of the methods provided in the above-described embodiments. The computer-readable storage medium may be a non-transitory computer-readable medium.

[0184] The computer-readable storage medium can be any available medium or data storage device that a computer can access, including but not limited to magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MOs), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)).

[0185] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An information processing method for processing questions raised by users, characterized in that, The method includes: The user submits a question to the search module, which then retrieves a set of matching knowledge fragments. For each knowledge fragment in the knowledge fragment set, the corresponding document fragment is located using the knowledge fragment, generating a document fragment set including at least one document fragment; the document fragment set is placed into a co-occurrence graph, and high-frequency co-occurrence community analysis is performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community; a target high-frequency co-occurrence community is selected from the at least one high-frequency co-occurrence community for training, generating a LoRA plugin corresponding to the target high-frequency co-occurrence community; Furthermore, the system generates question information using the knowledge fragment set and the user-submitted question; locates the corresponding LoRA plugin set based on the knowledge fragment set and determines the plugin set information of that LoRA plugin set; generates a question using the question information and the plugin set information, and sends the question to the LLM cluster; through the load balancing server in the LLM cluster, based on the plugin set information in the question, routes the question to the target LLM, loads the LoRA plugin in the target LLM to perform reasoning on the question, and generates answer content to be output to the user.

2. The method according to claim 1, characterized in that, High-frequency co-occurrence community analysis was performed on the co-occurrence graph to obtain at least one high-frequency co-occurrence community, including: The co-occurrence relationship graph of document fragments is constructed or updated using the co-occurrence relationship graph; According to preset rules, high-frequency co-occurrence communities are detected for the co-occurrence relationship graph of the document fragments.

3. The method according to claim 2, characterized in that, The document fragment co-occurrence relationship graph includes multiple nodes, each node being a document fragment; The construction of the document fragment co-occurrence graph includes: The RAG component outputs at least one knowledge fragment related to the question raised by the user. Determine the document segment corresponding to each of the aforementioned knowledge segments; Based on document fragments that have co-occurrence relationships, a document fragment co-occurrence relationship graph is determined, where the nodes of the document fragment co-occurrence relationship graph are document fragments, and the edges between nodes indicate that there is a co-occurrence relationship between document fragments.

4. The method according to claim 3, characterized in that, The construction of the document fragment co-occurrence graph further includes determining the weights of edges between nodes using the following method: For every two nodes, the number of times the document fragments of these two nodes co-occur is determined as the basic weight; based on the basic weight and the time decay factor, the weight of the edge between these two nodes is determined.

5. The method according to claim 4, characterized in that, The time decay factor is a value that is dynamically adjusted based on the interval between the co-occurrence time of the document fragments of these two nodes and the current time.

6. The method according to claim 2, characterized in that, Update the co-occurrence graph of the document fragments, including: For each knowledge fragment, locate the corresponding document fragment based on the position of the knowledge fragment in the document; For each document fragment located, check whether the document fragment already exists in the document fragment co-occurrence relationship graph; if it does not exist, add a node for the document fragment in the document fragment co-occurrence relationship graph and initialize the attribute information of the document fragment; if it already exists, update the attribute information of the document fragment. For any pairwise relationships between all located document fragments, if there is no co-occurrence edge in the document fragment co-occurrence graph, a new edge is created and its weight is initialized; if a co-occurrence edge already exists, its attribute information is updated based on this co-occurrence behavior.

7. The method according to claim 2, characterized in that, The preset rules include one or a combination of the following rules: According to a preset period, high-frequency co-occurrence communities are periodically detected for the co-occurrence relationship graph of the document fragments; When the number of newly added nodes in the document fragment co-occurrence graph exceeds a preset threshold, high-frequency co-occurrence communities are detected for the document fragment co-occurrence graph.

8. The method according to claim 2, characterized in that, For the co-occurrence graph of the document fragments, high-frequency co-occurrence communities are detected, including: The document fragment co-occurrence graph was divided into high-frequency co-occurrence communities using the Leiden algorithm, resulting in at least one high-frequency co-occurrence community. Determine the overall weight of each of the aforementioned high-frequency co-occurrence communities.

9. The method according to claim 8, characterized in that, Determine the overall weight of each of the aforementioned high-frequency co-occurrence communities, including: For each of the aforementioned high-frequency co-occurrence communities, a weighted sum is performed based on one or a combination of the following parameters of the high-frequency co-occurrence community to obtain the comprehensive weight of the high-frequency co-occurrence community: This includes the total number of occurrences of all nodes within the high-frequency co-occurrence community, the total weight of edges, and the average retrieval ranking of document fragments.

10. The method according to claim 8, characterized in that, From the at least one high-frequency co-occurrence community, a target high-frequency co-occurrence community is selected for training to generate the LoRA plugin corresponding to the target high-frequency co-occurrence community: Select the high-frequency co-occurrence community with the highest comprehensive weight from the at least one high-frequency co-occurrence community as the target high-frequency co-occurrence community; For each document involved in the target high-frequency co-occurrence community, determine the set of document fragments of that document in the target high-frequency co-occurrence community, extract the training content from the set of document fragments through the GraphRAG knowledge graph of that document, and generate the training document based on the extracted training content and the structure of the document. A training document set is generated using the training documents of each document involved in the target high-frequency co-occurrence community; The document set to be trained is input into LoRA, and the LoRA plugin is obtained through LoRA training.

11. The method according to claim 10, characterized in that, For each document involved in the target high-frequency co-occurrence community, the training content is extracted from the document fragment set using the document's GraphRAG knowledge graph. Based on the extracted training content and the document's structure, a training document is generated, including: For each document involved in the target high-frequency co-occurrence community: The document was preprocessed using GraphRAG; Based on the preprocessed document, a GraphRAG knowledge graph is generated, wherein the GraphRAG knowledge graph includes multiple text blocks obtained by segmenting the document; For each document fragment in the document fragment set, locate the corresponding text block in the GraphRAG knowledge graph, and obtain the GraphRAG semantic community to which the text block belongs based on the entities and relationships associated with the text block; The text blocks corresponding to all entities and relations contained in each GraphRAG semantic community are included in the set of text blocks to be trained; For each text block in the set of text blocks to be trained, expand to the text blocks adjacent to it before and after the text block to form an expansion unit; For the target document that has undergone the preprocessing, its hierarchical structure and the content of each expansion unit are preserved. For the document area outside each expansion unit, a preset tag is used for replacement, and finally the training document corresponding to the target document is formed.

12. The method according to claim 11, characterized in that, Based on the preprocessed documents, a GraphRAG knowledge graph is generated, including: The preprocessed document is then divided into multiple text blocks according to its hierarchical structure. The LLM is invoked to process each text block, identify the entities within them, extract the relationships between the entities, obtain entity and relationship instances, and use the entity and relationship instances to initially construct the GraphRAG knowledge graph; The entities in the GraphRAG knowledge graph are grouped, and each group forms a semantic community. Generate a summary for each of the semantic communities; The text blocks and entities in the knowledge graph are converted into vectors and stored in a vector database. The GraphRAG knowledge graph, which contains structured data of the entities, relationships, and semantic communities, will be persistently stored.

13. The method according to claim 1, characterized in that, Based on the knowledge fragment set, the corresponding LoRA plugin set is located, and the plugin set information of the LoRA plugin set is determined, including: For each knowledge fragment in the knowledge fragment set, the corresponding document region is located based on the document and location information of the knowledge fragment, and the LoRA plugin corresponding to the knowledge fragment is determined based on the mapping relationship between the document region and the LoRA plugin. Using the LoRA plugins corresponding to each knowledge fragment in the knowledge fragment set, a LoRA plugin set is generated; By using the plugin information and weight information of each LoRA plugin in the LoRA plugin set, the plugin set information of the LoRA plugin set is generated.

14. The method according to claim 13, characterized in that, The mapping relationship between the document region and the LoRA plugin is maintained through an inverted index of the LoRA plugin and the document region, where the document region identifier is the key and the LoRA plugin identifier is the value.

15. The method according to claim 13, characterized in that, Based on the plugin set information in the query, the query is routed to the target LLM via the load balancer in the LLM cluster, including: By using the load balancing server in the LLM cluster, based on the LoRA plugin loading status and load of each LLM node, it is determined whether there is a target LLM node that has loaded all the required LoRA plugins that match the plugin set information and whose load is lower than a preset threshold. If it exists, the query will be routed to the target LLM; If none exists, the LLM with the most loaded plugins matching the plugin set information is identified as the target LLM, and a LoRA plugin loading instruction is sent to the target LLM node to instruct it to load the plugins not loaded in the plugin set information. After the target LLM node has completed loading all the required LoRA plugins matching the plugin set information, the query is routed to the target LLM.

16. The method according to claim 13, characterized in that, The LoRA plugin is loaded into the target LLM to perform reasoning on the question, generating an answer to be output to the user, including: For each LoRA plugin in the plugin set information, the influence coefficient of the LoRA plugin is set according to the weight information of the LoRA plugin; wherein, the higher the weight of the LoRA plugin, the greater the influence coefficient. Based on the influence coefficient of each LoRA plugin in the plugin set information, answer content is generated for output to the user, wherein the larger the influence coefficient of a LoRA plugin, the greater the influence of the LoRA plugin on the answer content.

17. The method according to claim 16, characterized in that, The weight information of the LoRA plugin is determined in the following way: For high-frequency co-occurrence communities that directly match the question, the corresponding LoRA plugin weight is positively correlated with the number of knowledge fragments matched by the high-frequency co-occurrence community in this RAG search. The more knowledge fragments matched, the higher the corresponding plugin weight. For high-frequency co-occurrence communities that do not directly match the question, the LoRA plugin weight corresponding to the high-frequency co-occurrence community that does not directly match is calculated by combining the plugin weight of the matched high-frequency co-occurrence communities and the total correlation between the high-frequency co-occurrence communities that do not directly match and the matched high-frequency co-occurrence communities. The total correlation is determined by summarizing the correlation between each high-frequency co-occurrence community that is periodically maintained. If the total correlation between a non-directly matched high-frequency co-occurrence community and a matched high-frequency co-occurrence community is lower than a preset threshold, the weight of the LoRA plugin corresponding to the non-directly matched high-frequency co-occurrence community is set to 0.

18. An information processing apparatus for processing questions raised by users, characterized in that, The device includes: The knowledge fragment set generation module is used to input the questions submitted by users into the retrieval module, and the retrieval module retrieves the matching knowledge fragment set. The fine-tuning training processing module is used to locate the corresponding document fragment for each knowledge fragment in the knowledge fragment set, generate a document fragment set including at least one document fragment; place the document fragment set into a co-occurrence relation graph, perform high-frequency co-occurrence community analysis on the co-occurrence relation graph to obtain at least one high-frequency co-occurrence community; select a target high-frequency co-occurrence community from the at least one high-frequency co-occurrence community for training, and generate the LoRA plugin corresponding to the target high-frequency co-occurrence community; The reasoning question-answering processing module is used to generate question information using the knowledge fragment set and the question submitted by the user; and to locate the corresponding LoRA plugin set based on the knowledge fragment set, and determine the plugin set information of the LoRA plugin set; to generate a question using the question information and the plugin set information, and send the question to the LLM cluster; through the load balancing server in the LLM cluster, based on the plugin set information in the question, the question is routed to the target LLM, and the target LLM loads the LoRA plugin to reason about the question, generating answer content to be output to the user.

19. An electronic device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method described in any one of claims 1 to 17 according to the obtained program.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing the computer to perform the method described in any one of claims 1 to 17.

Images