Knowledge question and answer processing method fusing large model and knowledge graph

Abstract

The invention discloses a knowledge question and answer processing method fusing a large model and a knowledge graph, and relates to the technical field of artificial intelligence and natural language processing. Aiming at the defects of a traditional retrieval enhancement generation technology in the aspects of complex semantic association, context consistency and dynamic knowledge updating, the scheme adopted by the invention comprises the following two stages: knowledge graph construction and mixed index generation: collecting and processing internal and external multi-source data of an enterprise, and performing cleaning preprocessing such as coding normalization and de-duplication to obtain a mixed index; entities and relations are extracted through a pre-training model to generate a triple, a knowledge graph is constructed and stored in Neo4j, then a mixed index is generated through text and graph embedding fusion, and two types of retrieval are supported; retrieval and answer generation: obtaining user query, preprocessing, vectorizing, obtaining a candidate list through low-level semantic retrieval and high-level reasoning retrieval, fusing multi-dimensional indexes, rearranging and screening top-M candidates through Cross-encoder, constructing a JSON evidence list, and generating traceable answers through small model draft, large model fine calibration and consistency verification.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and natural language processing technology, specifically a knowledge question answering method that integrates large models and knowledge graphs. Background Technology

[0002] As enterprises continue to advance their digital transformation, knowledge such as business systems and technical standards are constantly generated in various forms across different systems, including PDF scans, editable documents, database records, web page content, and instant messaging logs. The diverse sources, significant structural differences, and frequent version updates of this data lead to the following common practical problems faced by enterprises when performing knowledge retrieval, policy interpretation, and compliance audits:

[0003] 1. Knowledge is multi-sourced, heterogeneous, and lacks structured representation. A large amount of knowledge is stored in an unstructured manner, and the relationships between entities, such as references, revisions, and dependencies, cannot be recognized by the system. When users perform cross-chapter, multi-hop reasoning queries, traditional keyword-based or full-text search systems can only return discrete text and cannot recover the contextual logical chain.

[0004] 2. Frequent version updates lead to a high risk of knowledge obsolescence. Policies, regulations, and industry standards are being updated at increasingly rapid paces. Many business systems still rely on static knowledge bases or batch index rebuilding to maintain content updates, often resulting in delays, omissions, or conflicts, making it difficult to support the traceability requirements for "version basis" in compliance audits.

[0005] 3. Limitations of traditional search enhancement generation (RAG) schemes.

[0006] In recent years, RAG (Research and Analysis of Language) technology, which combines external knowledge retrieval with large language models, has received widespread attention in question-answering tasks. However, current mainstream RAG implementations generally rely on vector databases for flat semantic retrieval, which can only solve the problem of text fragment similarity recall: it cannot identify explicit logical relationships between entities; the retrieval results are fragmented and do not support reasoning chain tracing; it lacks source comparison and evidence verification mechanisms, and the generated content lacks credible explanatory power. Therefore, in scenarios that require reliable evidence chains (such as interpretation of legal basis, interpretation of insurance clauses, comparison of medical policies, identification of contract clause conflicts, etc.), direct generation based on large models is often prone to factual errors, reasoning jumps, or the inability to explain the basis (i.e., the "illusion" phenomenon), making it difficult to meet audit-level business requirements.

[0007] 4. Existing knowledge graph question answering also has shortcomings. Although knowledge graphs can perform structured modeling of entities and their relationships and support reasoning paths, pure graph question answering relies on predefined structures, has limited coverage, and has high expansion costs, making it unsuitable for open domains or frequently updated domains containing massive amounts of dynamic text. Summary of the Invention

[0008] This invention addresses the shortcomings of traditional Retrieval Augmentation Generation (RAG) technology in complex semantic associations, contextual consistency, and dynamic knowledge updates by providing a knowledge question answering method that integrates large models and knowledge graphs.

[0009] The present invention provides a knowledge question answering method that integrates large models and knowledge graphs, and the technical solution adopted to solve the above-mentioned technical problems is as follows:

[0010] A knowledge question answering method that integrates large-scale models and knowledge graphs includes the following two stages:

[0011] (I) Knowledge Graph Construction and Hybrid Index Generation Stage;

[0012] Step 1.1: Collect and process heterogeneous data from multiple sources inside and outside the enterprise to obtain text data and retain metadata;

[0013] Step 1.2: Perform encoding normalization, OCR-based page layout restoration, paragraph segmentation, deduplication based on rolling hash and edit distance, and targeted sentence segmentation and semantic segmentation cleaning and preprocessing operations on the text data in sequence to ensure the consistency, structure and usability of the text data;

[0014] Step 1.3: For the text data after cleaning and preprocessing, entity recognition and relation extraction are achieved through a pre-trained model to generate triples. After weak supervision optimization, a knowledge graph is constructed and stored in the graph database Neo4j.

[0015] Step 1.4: Based on the constructed knowledge graph, a hybrid index containing specified information is generated through a joint vector strategy combining text embedding and graph embedding, so as to simultaneously support vectorized semantic retrieval and graph-based reasoning retrieval.

[0016] (II) The stage of retrieval and answer generation based on user query needs;

[0017] Step 2.1: Obtain user query requirements. First, perform text preprocessing such as simplified / traditional Chinese conversion, number / unit normalization, and noise reduction. Then, complete intent recognition and slot extraction through a specified model. Finally, use a text embedding model consistent with the process of generating a hybrid index to vectorize the query requirements and output a query vector with specified meta-information to adapt to subsequent vectorized semantic retrieval and graph-based reasoning retrieval.

[0018] Step 2.2: Quickly obtain a list of semantically similar candidate segments from the vector database through low-level retrieval, and then perform high-level retrieval using either progressive or parallel execution modes to finally obtain a unified candidate list after sorting.

[0019] Step 2.3: Optimize the search results through multi-dimensional merging and multi-stage rearrangement. First, integrate the unified candidate list output by the high-level search, and then filter out the top-M candidate results that are adapted to LLM generation through precise sorting.

[0020] Step 2.4: Based on the top-M candidate results, first construct the candidate results into a JSON-formatted evidence list containing specified fields, and then generate the answer through the process of "small model to generate draft → large model / review model to refine → consistency verification", return it to the user, and ensure that the answer is based on the retrieved evidence and is traceable.

[0021] Optionally, step 1.1 specifically includes:

[0022] Step 1.1.1: Categorize and organize the heterogeneous data from multiple sources inside and outside the enterprise that need to be accessed. The data types include batch offline data, streaming / real-time data, and image / scanned document data.

[0023] Step 1.1.2: Select appropriate tool components to process the accessed data in a targeted manner: For various batch offline files, use text extraction and format conversion tools to parse different format files and extract text content; for streaming / real-time data, use access middleware to handle data change events and transmission processes to ensure real-time data synchronization and extract text information; for image / scanned data, use OCR tools to extract text information.

[0024] Step 1.1.3: Standardize the metadata fields for each text data record obtained after collection and processing, clearly specify the metadata content, and finally complete the transformation of multi-source heterogeneous data into text data, unified access and complete retention of metadata.

[0025] Further, optionally, step 1.2 specifically includes:

[0026] Step 1.2.1: Perform encoding format unification processing on the text data obtained in Step 1 to eliminate character garbled characters or parsing anomalies caused by different encoding standards, and ensure the basic readability and consistency of the text data;

[0027] Step 1.2.2: For the text data obtained by OCR recognition, restore the original document layout structure, correct the layout disorder caused during the OCR recognition process, improve the structure of the text, and provide accurate structural basis for subsequent paragraph segmentation.

[0028] Step 1.2.3: Based on the text content features, format specifications, and layout structure of the OCR text after encoding normalization, divide all text into paragraphs, clarify the logical hierarchy, and provide processing units of appropriate granularity for subsequent deduplication and semantic segmentation.

[0029] Step 1.2.4: The Rabin-Karp rolling hash algorithm is used to perform hash calculations on fixed-length segments in the text to quickly filter out potential duplicate content; then, a threshold is set by the Levenshtein distance to accurately match and deduplicate potential duplicate content, while recording the source list of the merged content to ensure that the deduplicated data is traceable and further improve the usability of the text data.

[0030] Step 1.2.5: Adopt differentiated sentence segmentation and semantic segmentation strategies for different types of text: For clause-type texts, strictly retain the identification information during sentence segmentation and segmentation to maintain their structured features; for prose-type texts, split independent sentences using sentence segmentation algorithms and combine them with paragraph clustering methods to divide semantic paragraphs based on semantic relevance, optimize the logical coherence of the text, and finally form structured and highly available text data.

[0031] Further optionally, step 1.3 specifically includes:

[0032] Step 1.3.1: For the text data after cleaning and preprocessing, a Chinese pre-trained model is selected for fine-tuning to obtain an entity recognition model, which can accurately identify the target entities in the text and output entity data containing specified information, providing a standardized basic entity set for the subsequent relation extraction process.

[0033] Step 1.3.2: For the text data after cleaning and preprocessing, and the entity data identified in Step 1.3.1, a dual-tower classification, sequence labeling, or span-pair classification strategy is adopted. The BERT pairclassification model or the SpanBERT+RelationClassifier model is selected for fine-tuning to obtain the relation extraction model. The relation extraction model is used to extract the association between the identified entities from the text, and output relation data containing specified information. This data is combined with the entity data output in Step 1.3.1 to form "entity-relation-entity" triples.

[0034] Step 1.3.3: Based on the entity recognition model obtained in Step 1.3.1 and the relation extraction model obtained in Step 1.3.2, the training data is expanded using a weakly supervised method combining rule constraints and remote supervision, based on thousands to tens of thousands of manually annotated initial corpora, to improve the model's generalization ability. At the same time, an online learning mechanism is introduced, using the manually verified entity recognition results and relation extraction results as incremental training samples to continuously optimize the recognition accuracy of the entity recognition model and the extraction accuracy of the relation extraction model, ensuring the reliability of the output results of the two models.

[0035] Step 1.3.4: Based on the entity data output in Step 1.3.1 and the triples generated in Step 1.3.2, design the graph model of the knowledge graph in combination with the specific business scenario, clarify the node type and edge type in the graph model, and construct a logically clear and hierarchical knowledge graph structure to ensure that the knowledge graph can accurately map the core information and the relationship between entities in the original text.

[0036] Step 1.3.5: Import the graph model designed in Step 1.3.4 and the triples generated in Step 1.3.2 into the graph database Neo4j, and retain the metadata of nodes and edges completely during the storage process.

[0037] Further optionally, step 1.4 specifically includes:

[0038] Step 1.4.1: For the text information associated with nodes in the knowledge graph, select an appropriate text embedding model for vectorization processing to transform the node text into text vectors that can represent semantic information.

[0039] Step 1.4.2: Based on the structural features of the knowledge graph, select a graph embedding algorithm to transform the structural relationships of nodes in the knowledge graph into structural vectors;

[0040] Step 1.4.3: Employ a differentiated joint strategy (a) or (b) to fuse the text vector and the structure vector into a unified hybrid vector:

[0041] (a) First, the text vector and the structure vector are directly integrated through the concatenation operation to obtain the combined vector. Then, the combined vector is mapped to the low-dimensional feature space that is suitable for the retrieval scenario through linear projection, and finally a unified hybrid vector is generated.

[0042] (b) First, a small MLP fusion network is constructed, and the text vector and structural vector are input into the network to perform deep semantic and structural information fusion learning, and directly output a hybrid vector with unified dimensions.

[0043] Step 1.4.4: Design a hybrid index structure that includes specified information and graph feature indicators. For each hybrid vector, synchronously associate and save the specified meta-information, non-meta-information core text association content, and graph structure indicators such as degree and centrality with nodes. Through standardized index upsert logic, traverse all nodes in the knowledge graph, and sequentially complete the hybrid vector generation, meta-information and core content association, and graph structure indicator calculation. Finally, generate a hybrid index in a vector database that supports vector retrieval and structured metadata filtering to support multi-dimensional retrieval needs.

[0044] Optionally, after constructing the knowledge graph and generating the hybrid index, the core idea of ​​"change detection → local extraction → differential merging → vector upsert / graphmerge" is adopted. This involves using change detection to locate changes in multi-source text data, performing local extraction and processing only on changed blocks, implementing graph differential merging based on entity parsing, updating the vector index, and recording audit logs as an incremental update strategy. This ensures the real-time performance and consistency of the knowledge graph and the hybrid index. This process specifically includes the following operations:

[0045] Step 1.5.1 Change Detection: For text data that has undergone cleaning and preprocessing, a differentiated detection method is used to locate the changed content: calculate checksums for source files or database records to verify integrity and identify changes; use change logs to capture data addition, modification or deletion operations in the database; use ETag or Last-Modified fields for web pages to determine whether there are content updates, accurately filter out the changed data that needs to be processed, and avoid indiscriminate full processing;

[0046] Step 1.5.2, Local Extraction: Only for the changed blocks identified by the change detection. If it is image-type text, the OCR operation is re-executed, and then entity recognition and relationship extraction operations are performed uniformly to generate or update the knowledge graph nodes and related relationships corresponding to the changed content.

[0047] Step 1.5.3, Differential Merging: Combining the entity system in the knowledge graph, the newly extracted nodes are matched with existing graph nodes: the same entity is identified through entity parsing technology, the duplicate entities are merged, and the newly added entities are added as nodes; at the same time, the relevant information of this merging operation is recorded in detail to ensure that it can be accurately traced if rollback is needed in the future, thus ensuring the consistency and maintainability of the knowledge graph;

[0048] Step 1.5.4, Vector upsert: For the knowledge graph nodes affected by differential merging, the hybrid vector is recalculated based on the "joint vector strategy combining text embedding and graph embedding", and the updated hybrid vector is upserted into the vector database; the vector database supports flexible configuration strategies such as multi-value storage or overlay storage of vector versions to ensure real-time synchronous updates of the hybrid index and the knowledge graph;

[0049] Step 1.5.5, Audit Log Recording: After each incremental update operation is completed, it is automatically written to the audit log to fully trace the entire incremental update process and provide support for subsequent problem investigation and version rollback.

[0050] Further, optionally, step 2.1 specifically includes:

[0051] Step 2.1.1: Perform text preprocessing such as simplified / traditional Chinese conversion, number / unit normalization, and noise reduction on the user's query requirements to eliminate format differences and redundant information in the query text, and provide standardized input for subsequent intent recognition, slot extraction and query vectorization.

[0052] Step 2.1.2: For the preprocessed standardized query text, the core information is extracted using a specified model: intent recognition is performed using a multi-classifier fine-tuned based on BERT to clarify the user's query purpose; slot extraction is performed using the BERT-CRF sequence labeling model to extract the specified information.

[0053] Step 2.1.3: Using the same text embedding model as the process of generating the hybrid index, the preprocessed query text that has completed intent recognition and slot extraction is converted into a vector, and finally the query vector v_q with specified meta-information is output, which provides a matching basis for subsequent vectorized semantic retrieval based on the hybrid index and graph-based reasoning retrieval.

[0054] Further, optionally, step 2.2 specifically includes:

[0055] Step 2.2.1, Low-level retrieval: Receive the query vector v_q with specified metadata, perform retrieval operations based on the vector database, and output a candidate fragment list containing similarity scores and corresponding metadata, providing a basic candidate set for subsequent high-level retrieval;

[0056] Step 2.2.2, High-level retrieval: Based on the candidate fragment list output by the low-level retrieval, and combined with the specified meta-information attached to the query vector v_q, a deep retrieval is performed progressively or in parallel to fully leverage the graph reasoning capabilities of the hybrid index.

[0057] (a) Progressive execution, specifically including: first, performing low-level retrieval to obtain a candidate fragment list, then selecting the top-N vector candidate nodes with the highest similarity from the candidate fragment list as trigger points, performing depth-limited BFS local expansion in the knowledge graph, expanding the expansion process according to edge weight / relation type, and finally calculating for each expansion path, merging and sorting all candidate results, and finally outputting a unified candidate list;

[0058] (b) Parallel execution, that is, two independent searches are triggered simultaneously in parallel to form a dual-path candidate acquisition mechanism: Path 1 is the vector search path, which directly calls the query vector v_q with specified metadata to perform low-level search and outputs a candidate fragment list containing similarity scores and corresponding metadata; Path 2 is the graph precise search path, which performs keyword search or index search of the knowledge graph based on the specified information extracted in step 2.1.2, directly locates the matching graph nodes and related content, and outputs a candidate node list; after the two searches are completed independently, the candidate fragment list and the candidate node list are merged, sorted by comprehensive scoring, and finally a unified candidate list is output;

[0059] Step 2.3 specifically includes:

[0060] Step 2.3.1, Candidate Merging: Receive the unified candidate list output by the high-level retrieval, and use the union operation to remove duplicates and complete the list, forming a complete candidate set without redundancy;

[0061] Step 2.3.2, Multi-stage re-ranking: Based on the candidate set, a BERT-based Cross-encoder is used as the fine-ranking model. The input format is [query; candidate_snippet]. The exact relevance score between the query and the candidate is directly output. Finally, the top-M candidates after ranking are output for LLM generation.

[0062] Further optionally, step 2.4 specifically includes:

[0063] Step 2.4.1, Evidence Structuring: Based on the top-M candidate results, extract key information to construct a standardized JSON format evidence list. Each piece of evidence must contain specified information.

[0064] Step 2.4.2: Generating a draft of the small model: Input the structured evidence list and the user's original query requirements into the small model. Relying on the efficiency of the small model, quickly process the evidence information and query intent to generate a preliminary draft answer. At the same time, extract key fact points from the draft answer.

[0065] Step 2.4.3, Large Model / Review Model Refinement: The large model or review model takes the draft answer generated by the small model, the extracted key fact points, the structured evidence list and the user's original query requirements as input. In accordance with the explicit instructions in the Prompt design guidelines to "generate answers based only on evidence, mark unverified facts and suggest manual review", the draft answer is precisely revised and optimized, details are added, expressions are standardized and the content is completely consistent with the evidence, and finally a high-quality answer is output.

[0066] Further, alternatively, the methods involved may include:

[0067] (A) For the final answer output by the structured evidence list and the large model / review model, fact extraction, evidence mapping, conflict detection, and confidence level aggregation are used to achieve fact tracing and illusion avoidance, and output an auditable output package containing the answer text and evidence chain information, specifically including:

[0068] (A1) Fact extraction: Using the final answer text generated by the large model / review model as input, candidate facts to be verified are extracted from the answer through information extraction model or regular / template matching, providing clear objects for subsequent matching and verification with the evidence list, and ensuring that the verification scope accurately covers the core information of the answer;

[0069] (A2) Evidence Mapping: For each extracted candidate fact, based on the constructed JSON format evidence list, matching evidence fragments are found through "text semantic similarity calculation + evidence comprehensive score weighting screening". The matching threshold is required to meet the preset standard. Facts that are successfully matched are marked as "verified" and associated with specified information to form a complete evidence chain, realizing direct traceability between the answer facts and the retrieved evidence. Facts that do not match valid evidence are marked as "unverified" and the reason for no matching evidence is recorded.

[0070] (A3) Conflict Detection: During the evidence mapping process, if a single fact matches multiple different versions of evidence in the evidence list, or if the content / core information of the matched evidence snippets contradict each other, the fact is immediately marked as "conflicted". The relevant information of each version of evidence and the corresponding comprehensive evidence score are sorted out and presented in the output package through conflict_notes. At the same time, conflict hints and conflict evidence source identifiers are marked for the answer.

[0071] (A4) Confidence Score Summary: Based on the comprehensive score of each piece of evidence in the evidence list, combined with the internal confidence estimate when the LLM outputs the answer, the final confidence score of each candidate fact is synthesized by the method of "weighted average of comprehensive evidence score × fact-evidence matching similarity", which quantifies the reliability of the facts and provides data support for the fact credibility assessment of the output package;

[0072] (B) Design a visual interface function to meet compliance requirements: This includes visually displaying the evidence chain path and evidence source versions, a version comparison view showing the differences and effective times of multiple versions, and operation audit logs recording key operation information. This enables visualized traceability and compliance auditing of the entire answer chain, as detailed below:

[0073] (B1) Visualization of the chain of evidence: Based on the relevant information of the output package and the original structured evidence list, the visualization interface intuitively displays the knowledge graph trigger path corresponding to each answer fact in a graphical way, clearly marks the relationship between each node, and also presents the original source file name, specific version number and fragment position of each piece of evidence, so that the evidence tracing chain of the answer is transformed from abstract data into visual content that can be viewed intuitively.

[0074] (B2) Version Comparison View: Based on version-related information of the structured evidence list, when the answer depends on multiple versions of evidence or there are version conflicts, the visualization interface displays the evidence fragments of different versions in parallel or comparative form, clearly marking the effective time and update time of each version, helping users to quickly identify version differences and core points of conflict, and providing intuitive support for manual review and decision-making;

[0075] (B3) Operation Audit Log: The visual interface clearly displays the user, time, type, object and result of each operation in the form of a timeline or list, ensuring that all key operations are traceable and auditable, and meeting compliance requirements.

[0076] The knowledge question answering method of the present invention, which integrates large models and knowledge graphs, has the following advantages compared with the prior art:

[0077] 1. This invention achieves more accurate, comprehensive and efficient knowledge question answering capabilities through a dual indexing mechanism, a two-layer retrieval framework, an incremental update mechanism and a generation optimization strategy. It can be widely applied to various scenarios such as search engines, intelligent customer service, education and tutoring, and medical assistance, and solves the shortcomings of traditional search augmentation generation (RAG) technology in terms of complex semantic association, contextual consistency and dynamic knowledge updates.

[0078] 2. This invention significantly improves the comprehensiveness and depth of knowledge acquisition through a two-layer retrieval mechanism; it organically combines knowledge graphs with vector representations, effectively solving the problem of flat knowledge expression; it fully leverages the advantages of the Large Language Model (LLM) in natural language generation, making the answers more in line with human expression habits and possessing high readability and interactive experience; combined with the logical support of multi-level graph retrieval, the credibility and verifiability of the answers are improved, avoiding the occurrence of "illusion" phenomena. Attached Figure Description

[0079] Appendix Figure 1 This is a flowchart of the knowledge graph construction and hybrid index generation stages in the method described in Embodiment 1 of the present invention;

[0080] Appendix Figure 2 This is a flowchart of the retrieval and answer generation stage based on user query requirements in the method described in Embodiment 1 of the present invention. Detailed Implementation

[0081] To make the technical solution, the technical problem solved, and the technical effect of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with specific embodiments.

[0082] Example 1:

[0083] Combined with appendix Figure 1 , 2 This embodiment proposes a knowledge question answering method that integrates large models and knowledge graphs, including the following two stages:

[0084] (I) Knowledge graph construction and hybrid index generation stage.

[0085] Step 1.1: Collect and process heterogeneous data from multiple sources both inside and outside the enterprise to obtain text data and retain metadata; this process specifically includes:

[0086] Step 1.1.1: Categorize and organize the heterogeneous data from multiple sources inside and outside the enterprise that need to be accessed. The data types cover batch offline data (such as .docx / .pdf / .xlsx / .txt format files, CSV / JSON files exported from the database), streaming / real-time data (such as Kafka / RabbitMQ message queue data, Webhook push data, log stream data), and image / scanned data (such as PDF scans, various image files);

[0087] Step 1.1.2: Select appropriate tool components to process the incoming data in a targeted manner: For various batch offline files, use text extraction and format conversion tools (such as Apache Tika, pdfminer, Pandoc) to parse different format files and extract text content; for streaming / real-time data, use access middleware (such as Kafka) to handle data change events and transmission processes, ensuring real-time data synchronization and extracting text information; for image / scanned data, use OCR tools (such as Tesseract, PaddleOCR) to extract text information.

[0088] Step 1.1.3: Standardize the metadata fields for each text data record obtained after collection and processing, and clearly specify the metadata content, including source_id (data source identifier), file_path (file path), ingest_time (access time), version_id (version identifier), section_id (chapter / paragraph identifier), page_no (page number), offset (offset), author (author), and checksum (checksum value). Finally, the transformation of multi-source heterogeneous data into text data, unified access, and complete retention of metadata are completed.

[0089] Step 1.2: Perform encoding normalization, OCR-based layout restoration, paragraph segmentation, deduplication based on rolling hash and edit distance (including source tracing), and targeted sentence segmentation and semantic segmentation cleaning and preprocessing operations on the text data in sequence to ensure the consistency, structure, and usability of the text data; this process specifically includes:

[0090] Step 1.2.1: Perform encoding format unification processing on the text data obtained in Step 1 to eliminate character garbled characters or parsing abnormalities caused by different encoding standards (such as UTF-8, GBK, etc.) and ensure the basic readability and consistency of the text data;

[0091] Step 1.2.2: For the text data obtained by OCR recognition, restore the original document's layout structure (such as heading levels, table layout, text-image correspondence, etc.), correct the layout disorder caused during OCR recognition, improve the text's structure, and provide accurate structural basis for subsequent paragraph segmentation.

[0092] Step 1.2.3: Based on the text content features, format specifications, and layout structure of the OCR text after encoding normalization, divide all text into paragraphs (segment segmentation), clarify the logical hierarchy, and provide processing units of appropriate granularity for subsequent deduplication and semantic segmentation.

[0093] Step 1.2.4: Using rolling hash algorithms such as Rabin-Karp, hash calculations are performed on fixed-length segments in the text to quickly filter out potential duplicate content; then, a threshold is set using Levenshtein distance (edit distance) to accurately match and deduplicate potential duplicate content, while recording the source list of the merged content to ensure that the deduplicated data is traceable and further improve the usability of the text data.

[0094] Step 1.2.5: Adopt differentiated sentence segmentation and semantic segmentation strategies for different types of text: For clause-type texts, strictly retain identification information such as chapter number and clause number during sentence segmentation and segmentation to maintain their structured characteristics; for prose-type texts, split independent sentences through sentence segmentation algorithms and combine them with paragraph clustering methods to divide semantic paragraphs based on semantic relevance, optimize the logical coherence of the text, and finally form structured and highly usable text data.

[0095] Step 1.3: For the text data after cleaning and preprocessing, entity recognition and relation extraction are performed using a pre-trained model to generate triples. After weak supervision optimization, a knowledge graph is constructed and stored in the graph database Neo4j. This process specifically includes:

[0096] Step 1.3.1: For the text data after cleaning and preprocessing, fine-tune a pre-trained Chinese model such as Chinese-BERT, ERNIE, or RoBERTa-wwm to obtain a Non-Entity Recognition (NER) model. This model accurately identifies target entities in the text and outputs entity data containing specified information such as entity_id (unique entity identifier), canonical_name (canonical name), type (entity type), span (text span), confidence (confidence level), source_id (data source identifier), and version (version number). This provides a standardized set of basic entities for subsequent relation extraction. It should be noted that to improve model development and deployment efficiency, the training and inference process of the entity recognition (NER) model can be efficiently implemented using open-source tools such as HuggingFace Transformers or by reusing mature internal fine-tuning frameworks.

[0097] Step 1.3.2: For the text data after cleaning and preprocessing, and the entity data identified in Step 1.3.1, strategies such as dual-tower classification, sequence labeling, or span-pair classification are adopted. Models such as BERTpairclassification and SpanBERT+RelationClassifier are selected for fine-tuning to obtain the relation extraction (RE) model. The relation extraction (RE) model extracts the relationships between the identified entities from the text and outputs relation data containing specified information src_entity (source entity), dst_entity (target entity), rel_type (relation type), properties (relation attributes), and confidence (confidence). This data is combined with the entity data output in Step 1.3.1 to form "entity-relation-entity" triples. It should be noted that, in order to improve the efficiency of model development and deployment, the training and inference process of the relation extraction (RE) model can be achieved efficiently by using open-source tools such as HuggingFace Transformers and OpenNRE, or by reusing mature internal fine-tuning frameworks.

[0098] Step 1.3.3: Based on the Entity Recognition (NER) model obtained in Step 1.3.1 and the Relation Extraction (RE) model obtained in Step 1.3.2, the training data is expanded using thousands to tens of thousands of manually annotated initial corpora as a foundation, combined with a weak supervision method of rule constraints and remote supervision (automatically annotating unannotated text using existing structured databases) to improve the model's generalization ability. At the same time, an online learning mechanism is introduced, using the manually verified entity recognition results and relation extraction results as incremental training samples to continuously optimize the recognition accuracy of the entity recognition (NER) model and the relation extraction (RE) model and relation extraction accuracy to ensure the reliability of the output results of the two models.

[0099] Step 1.3.4: Based on the entity data output in Step 1.3.1 and the triples generated in Step 1.3.2, design the graph model of the knowledge graph in combination with the specific business scenario, clarify the node types (such as Regulation, Clause, Term, Organization, etc., corresponding to the "type" field of the entity data) and edge types (such as apply_to, references, amends, etc., corresponding to the "rel_type" field of the relation data) in the graph model, and construct a logically clear and hierarchical knowledge graph structure to ensure that the knowledge graph can accurately map the core information in the original text and the relationship between entities;

[0100] Step 1.3.5: Import the graph model designed in Step 1.3.4 and the triples generated in Step 1.3.2 into the graph database Neo4j. During storage, the metadata of nodes and edges is fully preserved. The node metadata uses the source_id (data source identifier), version (version number), and confidence (confidence level) from the entity data, and adds ingest_time (data entry time) and evidence paragraph (the original text fragment corresponding to the entity). The edge metadata uses the confidence (confidence level) from the relation data, and adds source_id (source ID of the associated entity), version (version of the associated entity), ingest_time (data entry time), and evidence paragraph (the original text fragment corresponding to the relation). This ensures the full-link traceability of all data in the knowledge graph and provides support for subsequent graph queries, updates, and business applications.

[0101] Step 1.4: Based on the constructed knowledge graph, a hybrid index containing specified information is generated through a joint vector strategy combining text embedding and graph embedding to simultaneously support vectorized semantic retrieval (ANN) and graph-based reasoning retrieval (k-hop / path search); this process specifically includes:

[0102] Step 1.4.1: For the text information associated with nodes in the knowledge graph, select an appropriate text embedding model (it is recommended to use the sentence-transformers (SBERT) series model, or Chinese-SBERT, Qwen3-Embedding and other Chinese-specific embedding models) for vectorization processing, and convert the node text into text vectors (v_text) that can represent semantic information.

[0103] Step 1.4.2: Based on the structural features of the knowledge graph, select a graph embedding algorithm (if efficient generation is desired, unsupervised walking fast models such as node2vec and DeepWalk can be used; if text and graph structure information need to be integrated, GNN models based on neighbor aggregation such as GraphSAGE and GAT can be used) to transform the structural relationship of nodes in the knowledge graph into a structural vector (v_graph).

[0104] Step 1.4.3: Use a differentiated joint strategy (a) or (b) to fuse the text vector (v_text) and the structure vector (v_graph) into a unified hybrid vector (v_node):

[0105] (a) First, the text vector (v_text) and the structure vector (v_graph) are directly integrated through the concat operation to obtain the combined vector. Then, the combined vector is mapped to the low-dimensional feature space that is suitable for the retrieval scenario through linear projection, and finally a unified hybrid vector (v_node) is generated.

[0106] (b) First, a small MLP (Multilayer Perceptron) fusion network is constructed. The text vector (v_text) and the structure vector (v_graph) are input into the network to perform deep semantic and structural information fusion learning. The single hybrid vector (v_node) with unified dimension is directly output. This method can more closely combine text semantic information and graph structure relationship information, and ensure the accurate representation ability of the fused vector for the two types of information.

[0107] Step 1.4.4: Design a hybrid index structure that includes specified information and graph feature indicators. For each hybrid vector (v_node), synchronously associate and save metadata such as graph_node_id (graph node ID), source_id (data source identifier), and version (version number), as well as non-meta information such as the core text association content snippet and the degree, centrality, and graph structure indicators of the node. Through standardized index upsert logic, traverse all nodes in the knowledge graph, and sequentially complete the hybrid vector generation, metadata and core content association, and graph structure indicator calculation. Finally, generate a hybrid index in a vector database that supports vector retrieval and structured metadata filtering to support multi-dimensional retrieval needs.

[0108] After constructing the knowledge graph and generating the hybrid index, the core idea of ​​"change detection → local extraction → differential merging → vector upsert / graphmerge" is adopted. This involves a change detection strategy to locate changes in multi-source text data, performing local extraction and processing only on changed blocks, implementing graph differential merging based on entity parsing, updating the vector index, and recording audit logs. This incremental update strategy ensures the real-time performance and consistency of the knowledge graph and the hybrid index. This process specifically includes the following operations:

[0109] Step 1.5.1 Change Detection: For text data that has undergone cleaning and preprocessing, a differentiated detection method is used to locate changes: calculate checksums for source files or database records to verify integrity and identify changes; use change logs (CDC) to capture data addition, modification, or deletion operations in the database; use ETag or Last-Modified fields for web pages to determine if there are content updates, accurately filter out the changed data that needs to be processed, and avoid indiscriminate full processing;

[0110] Step 1.5.2, Local Extraction: Only for the changed blocks identified by the change detection, if it is image-type text, the OCR operation is re-executed, and then entity recognition (NER) and relation extraction (RE) operations are uniformly executed to generate or update the knowledge graph nodes and associations corresponding to the changed content;

[0111] Step 1.5.3, Differential Merging (Graph Merging Strategy): Combining the entity system in the knowledge graph, the newly extracted nodes are matched with existing graph nodes (wherein, existing graph nodes refer to the valid set of nodes that were stored in the knowledge graph before the incremental update operation was executed and formed after entity parsing, merging and deduplication, including all nodes that conform to the graph entity system specification generated during historical incremental updates or the first full construction, including node attributes, relationships and corresponding vector representation information): The same entity is identified through entity parsing technology (based on the specification name, the preset alias table and the fuzzy matching algorithm), the merging operation is performed on duplicate entities, and the node addition operation is performed on the newly added entities; at the same time, the relevant information of this merging operation is recorded in detail (including change type, entity / relationship ID involved, and state snapshot before the operation) to ensure that it can be accurately traced if a rollback is needed in the future, and to ensure the consistency and maintainability of the knowledge graph;

[0112] Step 1.5.4, Vector upsert: For knowledge graph nodes affected by differential merging (including newly added, modified nodes and nodes indirectly affected by changes in association relationships), recalculate the hybrid vector based on the "joint vector strategy combining text embedding and graph embedding", and upsert the updated hybrid vector into the vector database; the vector database supports flexible configuration strategies such as multi-value storage of vector versions (retaining historical versions) or overwrite storage (using the latest version), ensuring real-time synchronous updates of the hybrid index and the knowledge graph;

[0113] Step 1.5.5, Audit Log Recording: After each incremental update operation is completed, it is automatically written to the audit log. The log content includes ingest_id (unique identifier of the update task), affected_nodes (list of affected graph node IDs), operator (operator), timestamp (operation timestamp), rollback_token (rollback token), and change_type (change type: add / modify / delete), comprehensively tracing the entire incremental update process and providing support for subsequent problem investigation and version rollback.

[0114] (ii) The stage of searching and generating answers based on user query needs.

[0115] Step 2.1: Obtain user query requirements. First, perform text preprocessing including simplified / traditional Chinese conversion, number / unit normalization, and noise reduction. Then, complete intent recognition and slot extraction using a specified model. Finally, use a text embedding model consistent with the process of generating the hybrid index to vectorize the query requirements, outputting a query vector with metadata such as intent, slots, and time constraints to adapt to subsequent vectorized semantic retrieval and graph-based reasoning retrieval. This process specifically includes:

[0116] Step 2.1.1: Perform text preprocessing such as simplified / traditional Chinese conversion, number / unit normalization, and noise reduction on the user's query requirements to eliminate format differences and redundant information in the query text, and provide standardized input for subsequent intent recognition, slot extraction and query vectorization.

[0117] Step 2.1.2: For the preprocessed standardized query text, the core information is extracted using a specified model: a multi-classifier based on fine-tuned BERT such as Chinese-BERT / ERNIE (DistilBERT / TinyBERT can be selected for lightweight scenarios) is used to identify intent and clarify the user's query purpose; slot extraction is performed using the BERT-CRF sequence labeling model to extract specified information (such as date, subject, number);

[0118] Step 2.1.3: Using the same text embedding model as the process of generating the hybrid index, the preprocessed query text that has completed intent recognition and slot extraction is converted into a vector v_q. Finally, the query vector v_q with metadata such as intent, slots, and time constraints is output, providing a matching basis for subsequent vectorized semantic retrieval (ANN) based on the hybrid index and graph-based reasoning retrieval (k-hop / path search).

[0119] Step 2.2: Quickly obtain a list of semantically similar candidate segments from the vector database through low-level retrieval, and then perform high-level retrieval using either progressive or parallel execution modes to finally obtain a unified candidate list after ranking; this process specifically includes:

[0120] Step 2.2.1, Low-level retrieval (vectorized semantic retrieval, ANN): Receives a query vector v_q with metadata such as intent, slots, and time constraints. Relying on a vector database (containing hybrid vectors v_node and metadata such as node_id, source_id, version, and snippet), it performs a retrieval operation and outputs a candidate fragment list containing similarity scores and corresponding metadata, providing a basic candidate set for subsequent high-level retrieval.

[0121] Specifically, this is achieved through VectorDB.search(v_q, top_k=K1, filter=metadata_filters), where K1 is configured to 200 by default (flexible adjustment is supported). The similarity calculation uses the cosine or inner_product metric. The core objective is to quickly return 50 to 200 semantically similar candidate segments from top_k. Each candidate segment contains a similarity score and corresponding metadata, providing a basic candidate set for subsequent high-level retrieval.

[0122] Step 2.2.2, High-level retrieval (graph-based reasoning retrieval): Based on the candidate fragment list output by the low-level retrieval, and combined with the specified meta-information attached to the query vector v_q, deep retrieval is performed through the following two modes to fully leverage the graph reasoning capabilities of the hybrid index:

[0123] Mode A: Progressive execution, specifically including: first, performing low-level retrieval to obtain a candidate fragment list; then, selecting the top-N vector candidate nodes with the highest similarity from the candidate fragment list as trigger points; performing depth-constrained BFS local expansion in the knowledge graph; the expansion process prioritizing expansion based on edge weight / relation type; finally, calculating for each expansion path; merging and sorting all candidate results; and finally outputting a unified candidate list. The progressive execution mode has controllable computational cost and robust recall, making it suitable for most compliant scenarios.

[0124] The path calculation formula is:

[0125] path_score(p)=sum(edge_weight)*product(node_confidence)*decay(len(p))

[0126] In the formula, path_score(p) represents the score of path p; sum(edge_weight) represents the sum of edge weights; product(node_confidence) represents the product of node confidence; decay(len(p)) represents the decay function of path length, with decay(len) using exponential decay, such as 0.9^(len-1); this formula is a commonly used "path score calculation" formula in knowledge graph / path retrieval scenarios, used to quantify the credibility, importance, or relevance of a path;

[0127] Mode B: Parallel execution, which simultaneously triggers two independent searches in parallel, forming a dual-path candidate acquisition mechanism: Path 1 is a vector search path, which directly calls the query vector v_q with specified metadata to perform low-level retrieval and outputs a candidate fragment list containing similarity scores and corresponding metadata; Path 2 is a graph precise search path, which, based on the specified information (such as date, subject, number) extracted in step 2.1.2, performs keyword or index search of the knowledge graph to directly locate matching graph nodes and related content, and outputs a candidate node list; after the two searches are completed independently, the candidate fragment list and the candidate node list are merged and sorted by a comprehensive score (such as a weighted average of semantic similarity score and graph matching confidence), and finally outputs a unified candidate list. The advantage of the parallel execution mode is that the dual-path parallelism shortens the overall search time, especially suitable for scenarios with precise query conditions (such as containing explicit clause numbers or specific entity names) or extremely high real-time requirements, but because it starts two search processes simultaneously, it consumes more computing resources compared to the progressive execution mode.

[0128] Step 2.3: Optimize search results through multi-dimensional merging and multi-stage rearrangement. First, integrate the unified candidate list output by the high-level search, and then filter out the top-M candidate results adapted to LLM generation through precise sorting. This process specifically includes:

[0129] Step 2.3.1, Candidate Merging: Receive the unified candidate list output from the high-level retrieval, and use a union operation to remove duplicates and complete the candidate set, forming a complete candidate set without redundancy. During merging, a multi-dimensional weighted scoring formula is used to calculate the comprehensive score of the candidates, achieving effective integration of low-level vector retrieval and high-level path retrieval information. The comprehensive score formula is:

[0130] score = alpha * sim(query,

[0131] The formula is: sim(query, candidate.vec) + beta * path_score(candidate) + gamma * source_trust + delta * time_decay, where sim(query, candidate.vec) is the similarity score from the lower-level retrieval, path_score(candidate) is the path score from the higher-level retrieval, source_trust represents the data source trust score, time_decay represents the time decay coefficient, and candidate represents the candidate fragment. The default weight configuration is alpha = 0.5, beta = 0.3, gamma = 0.1, delta = 0.1 (which can be optimized based on business needs) to achieve effective fusion of the two retrieval information.

[0132] Step 2.3.2, Multi-stage re-ranking: Based on the candidate set, a BERT-based Cross-encoder is used as the fine-ranking model. The input format is [query; candidate_snippet], where query represents the query statement and candidate_snippet represents the candidate text fragment. The exact relevance score between the query and the candidate is directly output. Finally, the top-M candidates after ranking are output for LLM generation.

[0133] To balance performance and latency, a two-stage strategy of "coarse ranking with dual-tower model → fine ranking with cross-encoder" can be adopted. First, the top-K high-potential candidates are quickly screened out using the dual-tower model, and then fine ranking is performed on them to reduce computational costs. The tools / models used can be HuggingFaceTransformer (a cross-encoder based on human correlation data for fine-tuning) or a cross-encoder variant of Sentence-BERT. Finally, the sorted top-M candidates are output for LLM generation.

[0134] Step 2.4: Based on the top-M candidate results, first construct a JSON-formatted evidence list (structured evidence) containing specified fields, then generate the answer through the process of "small model draft generation → large model / review model fine-tuning → consistency verification," and return it to the user, ensuring that the answer is based on the retrieved evidence and is traceable. This process specifically includes:

[0135] Step 2.4.1, Evidence Structuring: Based on the top-M candidate results, extract key information to construct a standardized JSON-formatted evidence list. Each piece of evidence must include...

[0136] The specified information includes evidence_id (unique identifier of evidence), source_id (data source identifier), version (version number), section_id (chapter / paragraph identifier), snippet (text fragment), node_id (unique identifier of node), path_info (path information), and score (overall score). Among them, the core information such as snippet (text fragment) and score (overall score) are directly derived from the reordering results of the previous step, while node_id (unique identifier of node) and path_info (path information) are associated with the node and path data of the high-level graph retrieval, providing structured support for the evidence tracing in the subsequent answer generation.

[0137] Step 2.4.2: Generating a draft using a small model: Input the structured evidence list and the user's original query requirements into the small model (a lightweight pre-trained language model, referring to a lightweight pre-trained language model with a small number of parameters (usually in the range of 100M to 1B), fast inference speed, and low resource consumption, focusing on "efficiently completing simple tasks" without the need for complex semantic understanding or deep logical reasoning). Relying on the efficiency of the small model, quickly process the evidence information and query intent to generate a preliminary draft answer, and extract key fact points from the draft answer (which must correspond one-to-one with the core information in the evidence list).

[0138] Step 2.4.3, Large Model / Review Model Refinement: The large model (a pre-trained language model with a large number of parameters, usually in the range of 1B to 100B+, a heavyweight pre-trained language model with a large number of parameters, strong semantic understanding ability, accurate logical reasoning, and high generation quality, focusing on "deep optimization of complex tasks" and good at handling scenarios that require accurate semantic matching, logical verification, and natural language polishing) or the review model takes the draft answer generated by the small model, the extracted key fact points, the structured evidence list, and the user's original query requirements as input. In accordance with the explicit instructions in the Prompt design guidelines to "generate answers based only on evidence, label unverified facts and suggest manual review", the draft answer is precisely corrected and optimized, details are added, expressions are standardized and the content is completely consistent with the evidence, and finally a high-quality answer is output.

[0139] Step 2.5: Based on the final answer output by the structured evidence list and the large model / review model, fact extraction, evidence mapping, conflict detection, and confidence level summarization are performed to achieve fact tracing and illusion avoidance. An auditable output package containing the answer text, evidence chain, and other information is output, specifically including:

[0140] Step 2.5.1, Fact Extraction: Using the final answer text generated by the large model / review model as input, extract candidate facts to be verified (including core elements such as fact subject, attributes, relationships, and values) from the answer through information extraction model or regular / template matching. This provides clear objects for subsequent matching and verification with the evidence list, ensuring that the verification scope accurately covers the core information of the answer.

[0141] Step 2.5.2, Evidence Mapping: For each extracted candidate fact, based on the constructed JSON-formatted evidence list (including fields such as evidence_id, source_id, version, section_id, snippet, node_id, path_info, and score), matching evidence fragments are found through "text semantic similarity calculation + evidence comprehensive score weighting filtering," requiring the matching threshold to meet preset standards (e.g., similarity ≥ 0.7 and evidence score ≥ 0.3). Facts that are successfully matched are marked as "verified" and associated with the corresponding evidence_id, source_id, version, and path_info, forming a complete evidence chain to achieve direct tracing of the answer fact and the retrieved evidence; facts that do not match valid evidence are marked as "unverified," and the reason for no matching evidence is recorded (e.g., no relevant evidence, evidence similarity not meeting the standard).

[0142] Step 2.5.3, Conflict Detection: During the evidence mapping process, if a single fact matches multiple different versions of evidence in the evidence list, or if the content / core information of the matched evidence snippets contradict each other, the fact is immediately marked as "conflicting". The source_id (data source identifier), version (version number), core differences, and corresponding evidence score (comprehensive score) of each version of evidence are sorted out and presented in the output package through conflict_notes. At the same time, conflict hints and conflict evidence source identifiers are marked for the answer.

[0143] Step 2.5.4, Confidence Summarization: Based on the score of each piece of evidence in the evidence list, combined with the internal confidence estimate when LLM outputs the answer (such as token-level confidence or sentence-level confidence), the final confidence score (range 0-1) of each candidate fact is synthesized using the method of "weighted average of evidence comprehensive score × fact - evidence matching similarity". This quantifies the reliability of the fact and provides data support for the fact credibility assessment of the output package. The confidence score of "verified" facts is calculated according to the above formula, the confidence score of "unverified" facts is set to 0, and the confidence score of "conflicting" facts is the highest score among the matching evidence multiplied by the conflict coefficient (such as 0.5), providing data support for the fact credibility assessment of the output package.

[0144] Step 2.6: Design a visual interface function to meet compliance requirements: Visualize the evidence chain to show the path of the relationship diagram and the versions of the evidence sources; present the differences between multiple versions and their effective dates in a version comparison view; record key operation information in the operation audit log, achieving full-chain visual traceability and compliance auditing of the answer, as detailed below:

[0145] Step 2.6.1, Visualizing the Evidence Chain: Based on the evidence_chain (list of evidence IDs), fact_items (fact-evidence mapping relationship) in the output package and the path_info (path information), source_id (data source identifier), and version (version number) in the original structured evidence list, the visualization interface intuitively displays the knowledge graph trigger path corresponding to each answer fact in a graphical way, clearly marks the relationship between each node, and simultaneously presents the source_id (data source identifier), version (version number), and section_id (chapter / paragraph identifier) ​​of each piece of evidence, transforming the evidence tracing chain of the answer from abstract data into visually viewable content;

[0146] Step 2.6.2, Version Comparison View: Based on the version (version number), time_decay (time-related metadata) of the structured evidence list and the snippet (text fragment) of conflicting evidence, when the answer depends on multiple versions of evidence or there are version conflicts, the visualization interface displays the evidence fragments of different versions in parallel or comparative form, clearly marking the effective time, update time and other key information of each version, helping users quickly identify version differences and core conflict points, and providing intuitive support for manual review and decision-making;

[0147] Step 2.6.3, Operation Audit Log: The visual interface clearly displays detailed information such as the user, time, type, object, and result of each operation in the form of a timeline or list, ensuring that all key operations are traceable and auditable, and meeting compliance requirements.

[0148] In summary, the knowledge question answering method of this invention, which integrates large models and knowledge graphs, can achieve more accurate, comprehensive, and efficient knowledge question answering capabilities through a dual indexing mechanism, a two-layer retrieval framework, an incremental update mechanism, and a generation optimization strategy. It can be widely applied to various scenarios such as search engines, intelligent customer service, education and tutoring, and medical assistance, and solves the shortcomings of traditional retrieval augmentation generation (RAG) technology in terms of complex semantic association, contextual consistency, and dynamic knowledge updates.

[0149] The above specific examples illustrate the principles and implementation methods of the present invention in detail. These embodiments are merely for the purpose of helping to understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made to the present invention by those skilled in the art without departing from the principles of the present invention should fall within the patent protection scope of the present invention.

Claims

1. A knowledge question answering method that integrates large-scale models and knowledge graphs, characterized in that, It includes the following two stages: (I) Knowledge Graph Construction and Hybrid Index Generation Stage; Step 1.1: Collect and process heterogeneous data from multiple sources inside and outside the enterprise to obtain text data and retain metadata; Step 1.2: Perform encoding normalization, OCR-based page layout restoration, paragraph segmentation, deduplication based on rolling hash and edit distance, and targeted sentence segmentation and semantic segmentation cleaning and preprocessing operations on the text data in sequence to ensure the consistency, structure and usability of the text data; Step 1.3: For the text data after cleaning and preprocessing, entity recognition and relation extraction are achieved through a pre-trained model to generate triples. After weak supervision optimization, a knowledge graph is constructed and stored in the graph database Neo4j. Step 1.4: Based on the constructed knowledge graph, a hybrid index containing specified information is generated through a joint vector strategy combining text embedding and graph embedding, so as to simultaneously support vectorized semantic retrieval and graph-based reasoning retrieval. (II) The stage of retrieval and answer generation based on user query needs; Step 2.1: Obtain user query requirements. First, perform text preprocessing such as simplified / traditional Chinese conversion, number / unit normalization, and noise reduction. Then, complete intent recognition and slot extraction through a specified model. Finally, use a text embedding model consistent with the process of generating a hybrid index to vectorize the query requirements and output a query vector with specified meta-information to adapt to subsequent vectorized semantic retrieval and graph-based reasoning retrieval. Step 2.2: Quickly obtain a list of semantically similar candidate segments from the vector database through low-level retrieval, and then perform high-level retrieval using either progressive or parallel execution modes to finally obtain a unified candidate list after sorting. Step 2.3: Optimize the search results through multi-dimensional merging and multi-stage rearrangement. First, integrate the unified candidate list output by the high-level search, and then filter out the top-M candidate results that are adapted to LLM generation through precise sorting. Step 2.3 specifically includes: Step 2.3.1, Candidate Merging: Receive the unified candidate list output by the high-level retrieval, and use the union operation to remove duplicates and complete the list, forming a complete candidate set without redundancy; Step 2.3.2, Multi-stage re-ranking: Based on the candidate set, a BERT-based Cross-encoder is used as the fine-ranking model. The input format is [query; candidate_snippet]. The exact relevance score between the query and the candidate is directly output. Finally, the top-M candidates after ranking are output for LLM generation. Step 2.4: Based on the top-M candidate results, first construct the candidate results into a JSON-formatted evidence list containing specified fields, and then generate the answer through the process of "small model to generate draft → large model / review model to refine → consistency verification", return it to the user, and ensure that the answer is based on the retrieved evidence and is traceable.

2. The knowledge question answering method integrating large models and knowledge graphs according to claim 1, characterized in that, Step 1.1 specifically includes: Step 1.1.1: Categorize and organize the heterogeneous data from multiple sources inside and outside the enterprise that need to be accessed. The data types include batch offline data, streaming / real-time data, and image / scanned document data. Step 1.1.2: Select appropriate tool components to process the accessed data in a targeted manner: For various batch offline files, use text extraction and format conversion tools to parse different format files and extract text content; for streaming / real-time data, use access middleware to handle data change events and transmission processes to ensure real-time data synchronization and extract text information; for image / scanned data, use OCR tools to extract text information. Step 1.1.3: Standardize the metadata fields for each text data record obtained after collection and processing, clearly specify the metadata content, and finally complete the transformation of multi-source heterogeneous data into text data, unified access and complete retention of metadata.

3. The knowledge question answering method integrating large models and knowledge graphs according to claim 2, characterized in that, Step 1.2 specifically includes: Step 1.2.1: Perform encoding format unification processing on the text data obtained in Step 1 to eliminate character garbled characters or parsing anomalies caused by different encoding standards, and ensure the basic readability and consistency of the text data; Step 1.2.2: For the text data obtained by OCR recognition, restore the original document layout structure, correct the layout disorder caused during the OCR recognition process, improve the structure of the text, and provide accurate structural basis for subsequent paragraph segmentation. Step 1.2.3: Based on the text content features, format specifications, and layout structure of the OCR text after encoding normalization, divide all text into paragraphs, clarify the logical hierarchy, and provide processing units of appropriate granularity for subsequent deduplication and semantic segmentation. Step 1.2.4: The Rabin-Karp rolling hash algorithm is used to perform hash calculations on fixed-length segments in the text to quickly filter out potential duplicate content; then, a threshold is set by the Levenshtein distance to accurately match and deduplicate potential duplicate content, while recording the source list of the merged content to ensure that the deduplicated data is traceable and further improve the usability of the text data. Step 1.2.5: Adopt differentiated sentence segmentation and semantic segmentation strategies for different types of text: For clause-type texts, strictly retain the identification information during sentence segmentation and segmentation to maintain their structured features; for prose-type texts, split independent sentences using sentence segmentation algorithms and combine them with paragraph clustering methods to divide semantic paragraphs based on semantic relevance, optimize the logical coherence of the text, and finally form structured and highly available text data.

4. The knowledge question answering method integrating large models and knowledge graphs according to claim 3, characterized in that, Step 1.3 specifically includes: Step 1.3.1: For the text data after cleaning and preprocessing, a Chinese pre-trained model is selected for fine-tuning to obtain an entity recognition model, which can accurately identify the target entities in the text and output entity data containing specified information, providing a standardized basic entity set for the subsequent relation extraction process. Step 1.3.2: For the text data after cleaning and preprocessing, and the entity data identified in Step 1.3.1, a dual-tower classification, sequence labeling, or span-pair classification strategy is adopted. The BERT pairclassification model or the SpanBERT+RelationClassifier model is selected for fine-tuning to obtain the relation extraction model. The relation extraction model is used to extract the association between the identified entities from the text, and output relation data containing specified information. This data is combined with the entity data output in Step 1.3.1 to form "entity-relation-entity" triples. Step 1.3.3: Based on the entity recognition model obtained in Step 1.3.1 and the relation extraction model obtained in Step 1.3.2, the training data is expanded using a weakly supervised method combining rule constraints and remote supervision, based on thousands to tens of thousands of manually annotated initial corpora, to improve the model's generalization ability. At the same time, an online learning mechanism is introduced, using the manually verified entity recognition results and relation extraction results as incremental training samples to continuously optimize the recognition accuracy of the entity recognition model and the extraction accuracy of the relation extraction model, ensuring the reliability of the output results of the two models. Step 1.3.4: Based on the entity data output in Step 1.3.1 and the triples generated in Step 1.3.2, design the graph model of the knowledge graph in combination with the specific business scenario, clarify the node type and edge type in the graph model, and construct a logically clear and hierarchical knowledge graph structure to ensure that the knowledge graph can accurately map the core information and the relationship between entities in the original text. Step 1.3.5: Import the graph model designed in Step 1.3.4 and the triples generated in Step 1.3.2 into the graph database Neo4j, and retain the metadata of nodes and edges completely during the storage process.

5. The knowledge question answering method integrating large models and knowledge graphs according to claim 4, characterized in that, Step 1.4 specifically includes: Step 1.4.1: For the text information associated with nodes in the knowledge graph, select an appropriate text embedding model for vectorization processing to transform the node text into text vectors that can represent semantic information. Step 1.4.2: Based on the structural features of the knowledge graph, select a graph embedding algorithm to transform the structural relationships of nodes in the knowledge graph into structural vectors; Step 1.4.3: Employ a differentiated joint strategy (a) or (b) to fuse the text vector and the structure vector into a unified hybrid vector: (a) First, the text vector and the structure vector are directly integrated through the concatenation operation to obtain the combined vector. Then, the combined vector is mapped to the low-dimensional feature space that is suitable for the retrieval scenario through linear projection, and finally a unified hybrid vector is generated. (b) First, a small MLP fusion network is constructed, and the text vector and structural vector are input into the network to perform deep semantic and structural information fusion learning, and directly output a hybrid vector with unified dimensions. Step 1.4.4: Design a hybrid index structure that includes specified information and graph feature indicators. For each hybrid vector, synchronously associate and save the specified meta-information, non-meta-information core text association content, and graph structure indicators such as degree and centrality with nodes. Through standardized index upsert logic, traverse all nodes in the knowledge graph, and sequentially complete the hybrid vector generation, meta-information and core content association, and graph structure indicator calculation. Finally, generate a hybrid index in a vector database that supports vector retrieval and structured metadata filtering to support multi-dimensional retrieval needs.

6. The knowledge question answering method integrating large models and knowledge graphs according to claim 5, characterized in that, After constructing the knowledge graph and generating the hybrid index, the core idea of ​​"change detection → local extraction → differential merging → vector upsert / graphmerge" is adopted. This involves a change detection strategy to locate changes in multi-source text data, performing local extraction and processing only on changed blocks, implementing graph differential merging based on entity parsing, updating the vector index, and recording audit logs. This incremental update strategy ensures the real-time performance and consistency of the knowledge graph and the hybrid index. This process specifically includes the following operations: Step 1.5.1 Change Detection: For text data that has undergone cleaning and preprocessing, a differentiated detection method is used to locate the changed content: calculate checksums for source files or database records to verify integrity and identify changes; use change logs to capture data addition, modification or deletion operations in the database; use ETag or Last-Modified fields for web pages to determine whether there are content updates, accurately filter out the changed data that needs to be processed, and avoid indiscriminate full processing; Step 1.5.2, Local Extraction: Only for the changed blocks identified by the change detection. If it is image-type text, the OCR operation is re-executed, and then entity recognition and relationship extraction operations are performed uniformly to generate or update the knowledge graph nodes and related relationships corresponding to the changed content. Step 1.5.3, Differential Merging: Combining the entity system in the knowledge graph, the newly extracted nodes are matched with existing graph nodes: the same entity is identified through entity parsing technology, the duplicate entities are merged, and the newly added entities are added as nodes; at the same time, the relevant information of this merging operation is recorded in detail to ensure that it can be accurately traced if rollback is needed in the future, thus ensuring the consistency and maintainability of the knowledge graph; Step 1.5.4, Vector upsert: For the knowledge graph nodes affected by differential merging, the hybrid vector is recalculated based on the "joint vector strategy combining text embedding and graph embedding", and the updated hybrid vector is upserted into the vector database; the vector database supports flexible configuration strategies such as multi-value storage or overlay storage of vector versions to ensure real-time synchronous updates of the hybrid index and the knowledge graph; Step 1.5.5, Audit Log Recording: After each incremental update operation is completed, it is automatically written to the audit log to fully trace the entire incremental update process and provide support for subsequent problem investigation and version rollback.

7. The knowledge question answering method integrating large models and knowledge graphs according to claim 6, characterized in that, Step 2.1 specifically includes: Step 2.1.1: Perform text preprocessing such as simplified / traditional Chinese conversion, number / unit normalization, and noise reduction on the user's query requirements to eliminate format differences and redundant information in the query text, and provide standardized input for subsequent intent recognition, slot extraction and query vectorization. Step 2.1.2: For the preprocessed standardized query text, the core information is extracted using a specified model: intent recognition is performed using a multi-classifier fine-tuned based on BERT to clarify the user's query purpose; slot extraction is performed using the BERT-CRF sequence labeling model to extract the specified information. Step 2.1.3: Using the same text embedding model as the process of generating the hybrid index, the preprocessed query text that has completed intent recognition and slot extraction is converted into a vector, and finally the query vector v_q with specified meta-information is output, which provides a matching basis for subsequent vectorized semantic retrieval based on the hybrid index and graph-based reasoning retrieval.

8. The knowledge question answering method integrating large models and knowledge graphs according to claim 7, characterized in that, Step 2.2 specifically includes: Step 2.2.1, Low-level retrieval: Receive the query vector v_q with specified metadata, perform retrieval operations based on the vector database, and output a candidate fragment list containing similarity scores and corresponding metadata, providing a basic candidate set for subsequent high-level retrieval; Step 2.2.2, High-level retrieval: Based on the candidate fragment list output by the low-level retrieval, and combined with the specified meta-information attached to the query vector v_q, a deep retrieval is performed progressively or in parallel to fully leverage the graph reasoning capabilities of the hybrid index. (a) Progressive execution, specifically including: first, performing low-level retrieval to obtain a candidate fragment list, then selecting the top-N vector candidate nodes with the highest similarity from the candidate fragment list as trigger points, performing depth-limited BFS local expansion in the knowledge graph, expanding the expansion process according to edge weight / relation type, and finally calculating for each expansion path, merging and sorting all candidate results, and finally outputting a unified candidate list; (b) Parallel execution, that is, two independent searches are triggered simultaneously in parallel to form a dual-path candidate acquisition mechanism: Path 1 is the vector search path, which directly calls the query vector v_q with specified metadata to perform low-level search and outputs a candidate fragment list containing similarity scores and corresponding metadata; Path 2 is the graph precise search path, which performs keyword search or index search of the knowledge graph based on the specified information extracted in step 2.1.2, directly locates the matching graph nodes and related content, and outputs a candidate node list; after the two searches are completed independently, the candidate fragment list and the candidate node list are merged, sorted by comprehensive scoring, and finally a unified candidate list is output; Step 2.3 specifically includes: Step 2.3.1, Candidate Merging: Receive the unified candidate list output by the high-level retrieval, and use the union operation to remove duplicates and complete the list, forming a complete candidate set without redundancy; Step 2.3.2, Multi-stage re-ranking: Based on the candidate set, a BERT-based Cross-encoder is used as the fine-ranking model. The input format is [query; candidate_snippet]. The exact relevance score between the query and the candidate is directly output. Finally, the top-M candidates after ranking are output for LLM generation.

9. The knowledge question answering method integrating large models and knowledge graphs according to claim 8, characterized in that, Step 2.4 specifically includes: Step 2.4.1, Evidence Structuring: Based on the top-M candidate results, extract key information to construct a standardized JSON format evidence list. Each piece of evidence must contain specified information. Step 2.4.2: Generating a draft of the small model: Input the structured evidence list and the user's original query requirements into the small model. Relying on the efficiency of the small model, quickly process the evidence information and query intent to generate a preliminary draft answer. At the same time, extract key fact points from the draft answer. Step 2.4.3, Large Model / Review Model Refinement: The large model or review model takes the draft answer generated by the small model, the extracted key fact points, the structured evidence list and the user's original query requirements as input. In accordance with the explicit instructions in the Prompt design guidelines to "generate answers based only on evidence, mark unverified facts and suggest manual review", the draft answer is precisely revised and optimized, details are added, expressions are standardized and the content is completely consistent with the evidence, and finally a high-quality answer is output.

10. The knowledge question answering method integrating large models and knowledge graphs according to claim 9, characterized in that, The method further includes: (A) For the final answer output by the structured evidence list and the large model / review model, fact extraction, evidence mapping, conflict detection, and confidence level aggregation are used to achieve fact tracing and illusion avoidance, and output an auditable output package containing the answer text and evidence chain information, specifically including: (A1) Fact extraction: Using the final answer text generated by the large model / review model as input, candidate facts to be verified are extracted from the answer through information extraction model or regular / template matching, providing clear objects for subsequent matching and verification with the evidence list, and ensuring that the verification scope accurately covers the core information of the answer; (A2) Evidence Mapping: For each extracted candidate fact, based on the constructed JSON format evidence list, matching evidence fragments are found through "text semantic similarity calculation + evidence comprehensive score weighting screening". The matching threshold is required to meet the preset standard. Facts that are successfully matched are marked as "verified" and associated with specified information to form a complete evidence chain, realizing direct traceability between the answer facts and the retrieved evidence. Facts that do not match valid evidence are marked as "unverified" and the reason for no matching evidence is recorded. (A3) Conflict Detection: During the evidence mapping process, if a single fact matches multiple different versions of evidence in the evidence list, or if the content / core information of the matched evidence snippets contradict each other, the fact is immediately marked as "conflicted". The relevant information of each version of evidence and the corresponding comprehensive evidence score are sorted out and presented in the output package through conflict_notes. At the same time, conflict hints and conflict evidence source identifiers are marked for the answer. (A4) Confidence Score Summary: Based on the comprehensive score of each piece of evidence in the evidence list, combined with the internal confidence estimate when the LLM outputs the answer, the final confidence score of each candidate fact is synthesized by the method of "weighted average of comprehensive evidence score × fact-evidence matching similarity", which quantifies the reliability of the facts and provides data support for the fact credibility assessment of the output package; (B) Design a visual interface function to meet compliance requirements: This includes visually displaying the evidence chain path and evidence source versions, a version comparison view showing the differences and effective times of multiple versions, and operation audit logs recording key operation information. This enables visualized traceability and compliance auditing of the entire answer chain, as detailed below: (B1) Visualization of the chain of evidence: Based on the relevant information of the output package and the original structured evidence list, the visualization interface intuitively displays the knowledge graph trigger path corresponding to each answer fact in a graphical way, clearly marks the relationship between each node, and also presents the original source file name, specific version number and fragment position of each piece of evidence, so that the evidence tracing chain of the answer is transformed from abstract data into visual content that can be viewed intuitively. (B2) Version Comparison View: Based on version-related information of the structured evidence list, when the answer depends on multiple versions of evidence or there are version conflicts, the visualization interface displays the evidence fragments of different versions in parallel or comparative form, clearly marking the effective time and update time of each version, helping users to quickly identify version differences and core points of conflict, and providing intuitive support for manual review and decision-making; (B3) Operation Audit Log: The visual interface clearly displays the user, time, type, object and result of each operation in the form of a timeline or list, ensuring that all key operations are traceable and auditable, and meeting compliance requirements.

Images