A versioned consistency checking system and method for language generation

Abstract

The present application is suitable for the field of data consistency verification, and provides a versioned consistency verification system and method for language generation, which comprises a knowledge unit generation module for splitting text into knowledge slices and defining semantic vectors; a knowledge unit certificate generation module for giving hash certificates; a versioned certificate storage database for storing block contents, corresponding semantic vectors, block / vector identification codes and hash certificates; an access control module for authorizing and recording knowledge base data access and modification operations; a vector pre-reading storage module for storing corresponding block identification codes of vector data; a question unit generation module for generating question slices, question semantic vectors and question block / vector identification codes; and a retriever for block / vector identification code retrieval. Thus, the present application can solve the problem of security risks in ensuring data authenticity and consistency of existing RAG systems.

Description

TECHNICAL FIELD

[0001] The present application is suitable for the field of data consistency verification, and provides a versioned consistency verification system and method for language generation. BACKGROUND

[0002] Generating Retrieval-Augmented Generation (RAG) system is a natural language processing (NLP) method based on the combination of retrieval and generation. Its core idea is to combine the information retrieval function in the external knowledge base with the generative language model, so that the language model can generate more accurate and context-related text. RAG system first finds the information related to the input query from large-scale databases or documents through the retrieval engine, and then generates text combined with the retrieved information. This method effectively improves the knowledge breadth of the language model and the relevance of the answer.

[0003] The workflow of RAG system can be briefly summarized as follows: first, the user inputs a query or question, and the system extracts the document fragments or information related to the query from the knowledge base through the preset retrieval algorithm. Then, these retrieved document fragments are passed to the generation module, which generates appropriate answers or text based on the input query and retrieved information. Thus, RAG system can supplement the generated content with external knowledge base, making it have higher context consistency, thereby improving the quality of the output results.

[0004] However, traditional RAG systems still face many problems in application, especially in data consistency verification and knowledge base security protection. First, existing RAG technology lacks effective data consistency verification mechanism and knowledge base tamper protection. In some fields involving sensitive data, such as company financial reports, critical system parameters or government statistical data, if the data or documents are maliciously tampered with or forged, it may cause the system to generate incorrect answers, resulting in serious consequences. Specifically, for the storage layer, the slice content and vector in the RAG system do not have built-in integrity verification mechanism, which allows attackers to tamper with the slice content through data poisoning, resulting in incorrect results of the system; in addition, attackers can directly tamper with the slice vector, thereby destroying the similarity matching process, "semantic poisoning", interfering with the correctness and accuracy of the system. In addition, accidental data inconsistency caused by data synchronization delay, ETL process error, data damage caused by system bugs, accidental merging of different version data sources, and unintentional operator errors will cause data inconsistency. For the application layer, as the upper language model (LLM) that finally uses the retrieval results, it lacks the corresponding verification mechanism and cannot identify and detect whether the referenced knowledge fragment has been tampered with or is unreliable. Therefore, the existing RAG system has a great security risk in ensuring data authenticity and consistency. SUMMARY

[0005] In view of the above defects, the purpose of the present application is to provide a versioned consistency verification system for language generation, which aims to solve the problems raised in the background art. The system comprises:

[0006] A knowledge unit generation module capable of segmenting text into several knowledge slices and defining semantic vectors for each knowledge slice;

[0007] A knowledge unit certificate generation module capable of assigning a hash certificate to a knowledge slice;

[0008] A versioned certificate evidence database for storing intermediate data and result data generated in the segmentation, semantic vector definition and certificate generation steps of the knowledge unit; the intermediate data and result data specifically include: block content, corresponding semantic vector, block / vector identification code, and hash certificate associated with block / vector identification code, version number and operation entity information;

[0009] An access control module for authorizing and recording knowledge base data access and modification operations;

[0010] A vector pre-reading storage module for storing the corresponding block identification code of the vector data;

[0011] A question unit generation module for generating question slices, question semantic vectors and question block / vector identification codes;

[0012] A retriever for chunk / vector identification code retrieval in a vector pre-read storage module.

[0013] Further, the versioned credential evidence database is used to record the complete credential history of each knowledge unit for each legal processing, while the hash of the knowledge unit slice data block and semantic vector is stored as evidence.

[0014] Further, the hash credential in the versioned credential evidence database is stored in the credential evidence database as a record with the chunk / vector identification code, version number, and operation entity information to ensure relevance.

[0015] Further, the system further includes a context verification module for hash value verification of the knowledge slice and data vector corresponding to the extracted chunk / vector identification code.

[0016] A versioned consistency verification method for language generation based on a versioned consistency verification system for language generation, comprising the following logical steps:

[0017] S1, knowledge processing; process the original document into protected knowledge units, and complete the initial trusted evidence;

[0018] S2, build a protected retrieval index, build a vector pre-read storage library, and store small volume data content including chunk / vector identification code and semantic vector V;

[0019] S3, user query, and complete secure retrieval and consistency verification under the principle of "zero trust", including the following steps:

[0020] S3.1, receive user input query, and convert the problem into one or more query chunk / vector identification codes using the same rules as in S1.2;

[0021] S3.2, generate a set of query chunk / vector identification codes, and perform similarity retrieval in the vector pre-read storage module;

[0022] S3.3, the retriever returns the top-K most similar candidate chunk / vector identification codes; then the system intercepts and submits them to the context verification gateway to trigger the integrity verification process;

[0023] S3.4, context consistency verification;

[0024] S4, the safe generation stage generates answers using the knowledge that passes the verification.

[0025] Further, the step S1 specifically includes the following steps:

[0026] S1.1, using a specified chunking strategy, the input original document is segmented into multiple cohesive slice data blocks C. Call the preset embedding model to generate the semantic vector V of each slice data block C in the vector space;

[0027] S1.2, generate chunk / vector identification code;

[0028] Based on the content, field attribute and technical direction of the slice data block C, the chunk / vector identification code with semantic representation ability is generated; the chunk / vector identification code has semantic interpretability, that is, the core field and content direction of the knowledge chunk corresponding to the chunk / vector identification code can be inferred by analyzing the chunk / vector identification code itself, without accessing the original data;

[0029] S1.3, store the results of the above steps in the versioned credential evidence database.

[0030] Further, after the step S1.2, the system generates a knowledge unit hash credential, which is specifically:

[0031] The hash value of the slice data block C and the hash value of the corresponding semantic vector V are calculated respectively, and the hash values of the two are combined to generate a combined credential H which can cryptographically strongly associate the hash value of the slice data block with the hash value of its semantic vector.

[0032] Further, in the step S3.4, for each candidate chunk / vector identification code, the following verification steps are performed:

[0033] S3.4.1, extracting data to be verified according to the identification code: according to the candidate chunk / vector identification code, the corresponding latest version of the slice data block C, the semantic vector V and the final combined credential H stored previously are extracted from the versioned credential evidence database;

[0034] S3.4.2, real-time recalculation and comparison: using the same algorithm as S1.3, based on the extracted C, V, the combined credential Hc is recalculated in real time.

[0035] S3.4.3, verification decision: compare the recalculated Hc with the original H in the database;

[0036] If consistent: it proves that the knowledge unit has not been tampered with since the evidence is stored, the data is complete and valid, and the verification is passed;

[0037] If inconsistent: it proves that the knowledge unit has been tampered with, and the verification fails; the unit will be marked as abnormal and discarded.

[0038] Further, the step S4 specifically includes the following sub-steps:

[0039] S4.1, combine all the slice data blocks C of the knowledge units verified by S3.4 to constitute a security context verified for integrity together with the original query of the user;

[0040] S4.2, submit the security context to the generation model to generate a final answer based on the trusted reference materials.

[0041] Further, the system records the block / vector identification code and version number of all the knowledge units used in this query, so that the knowledge units can be traced back, the historical state can be verified, and the tampering behavior can be located through the block / vector identification code.

[0042] Therefore, the present application has the following beneficial effects:

[0043] 1. By using the HASH values of the content and semantic vectors and the combined credentials, direct tampering of the original content and secret tampering of the vector representation can be detected at the same time, which fundamentally cuts off the path of contaminated data flowing to the generation model, and solves the core problem that the prior art is difficult to defend against semantic poisoning attacks.

[0044] 2. The problem of huge computational overhead and delay caused by directly performing real-time verification in the massive vector database containing complete knowledge units in the prior art is solved. The block / vector identification code is stored in the vector pre-reading storage module and is subsequently retrieved, while ensuring efficient retrieval process and high security.

[0045] 3. The block / vector identification code generated by the present application is an interpretable and semantically representative unique identification generated by a preset rule according to the content and field attributes of the knowledge block, so that the query vector can also generate an identification code of the same rule. The similarity matching between the identification codes in the pre-reading module is more efficient than directly calculating the similarity of high-dimensional vectors, and the semantic matching is more accurate. The problem that the traditional random identification code cannot carry any semantic information, resulting in low efficiency of retrieval and subsequent audit tracing and lack of pertinence is solved.

[0046] 4. By using the versioned credential evidence database, not only the HASH credentials are stored, but also the version number, timestamp, and operation entity identity information of each change of each knowledge unit are recorded, which provides complete compliance guarantee for the legal iteration and maintenance of the knowledge base. BRIEF DESCRIPTION OF DRAWINGS

[0047] Figure 1 RAG is a flowchart. DETAILED DESCRIPTION

[0048] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0049] Retrieval Augmentation (RAG) techniques were widely used in the construction of "digital databases" during the era of large modeling, providing external knowledge and reference corpora for front-end Large Language Model (LLM) applications. A typical RAG workflow is shown in the appendix. Figure 1 As shown, the original document is first sliced, then each slice is vectorized, and the original slice content and vectors are stored in pairs in a vector database (knowledge base). When a user asks a question, the question is first vectorized, and then similar original slice content is found from the knowledge base through vector similarity search, such as cosine. The user's question and the slice content references are submitted to the large model for question answering.

[0050] The purpose of this invention is to provide a versioning consistency verification system and method for language generation, aiming to provide a strengthened and auditable data integrity and consistency guarantee layer for standard retrieval-enhanced generation systems (i.e., RAG systems). The core of this technical solution lies in introducing a centralized trusted credential management system and deeply integrating it into the RAG data processing chain.

[0051] The versioning consistency verification system for language generation includes: a knowledge unit generation module, a knowledge unit credential generation module, a versioned credential generation module, an access control module, a vector storage module, a retrieval module, and a context verification module.

[0052] The knowledge unit generation module uses a specified chunking strategy to divide the text into cohesive knowledge slices. Each segmented knowledge slice is defined as a slice data block, abbreviated as C. The module calls a preset embedding model to define a semantic vector for each slice data block in the vector space, abbreviated as V. The slice data blocks and their corresponding semantic vectors are then stored in the database.

[0053] The versioned credential generation module assigns and calculates the hash credentials of the slice data block and the corresponding semantic vector, that is, calculates the combined credentials H of the "knowledge unit" composed of (C, V), ensuring the atomic association between the source text and its semantic vector representation. A preferred embodiment is that the combined credentials are generated by concatenating the data block hash value H C and the semantic vector hash value H V, and then hashing the concatenated result, that is, H(H C||H V). Of course, those skilled in the art can understand that other cryptographic operations that can achieve similar strong association effects, such as XOR operation and then hashing of the two hash values, or using other algebraic operation methods, also belong to the protection scope of the present application. By calculating the combined credentials on the hash values instead of jointly calculating the original long string and vector, the calculation efficiency can be significantly improved in subsequent verification steps, especially when processing a large number of candidate knowledge units in batches. The hash algorithm preferably uses the national cryptographic algorithm issued by the National Cryptographic Administration, such as SM3; in compatible international scenarios, other certified cryptographic hash functions such as SHA-256, SHA-3, or BLAKE2 can also be used.

[0054] The intermediate data and result data generated in the segmentation of the knowledge unit, the definition of the semantic vector, and the credential generation steps in the above knowledge unit generation module and versioned credential generation module are stored in the versioned credential storage database. The versioned credential storage database uses an independent database system with high security and transaction integrity, which is used to record the complete credential history of each legal processing of each knowledge unit. At the same time, the system can also store the hash of the slice data block and the semantic vector of the knowledge unit to ensure the integrity and tamper resistance of its source and attribute information. Optionally, the database can record the identity of the authorized entity performing the change operation.

[0055] In the process of storing the vector in the versioned credential storage database, the block content and the corresponding semantic vector are stored, and the block / vector identification code is returned. The hash credentials, the block / vector identification code, the version number, and the operation entity information (such as user identification code, access IP) are stored as a record in the credential storage database.

[0056] The access control module provides support for the management of the entire life cycle of the knowledge base data. The knowledge base shard may involve legal modification operations, and the system provides governance capabilities for such legal knowledge base iteration and maintenance, ensuring that all change operations on the knowledge base slice are authorized and recorded.

[0057] The vector pre-reading storage module is an identification code library of the corresponding block of the vector data "based on the versioned credential storage database", and is configured with an efficient retriever. The vector pre-reading storage module and the retriever work together to store the block / vector identification codes corresponding to the massive knowledge slices and data vectors.

[0058] For the vectorization retrieval of user problems, the problem unit generation module is used to generate the multi-partition / vector identification code of the problem in the same rule as the knowledge unit generation module. The multi-partition / vector identification code generated after the vectorization of multiple problems is directly retrieved or similarity retrieved in the vector pre-reading storage module, so that all slices in the database are quickly and completely traversed, and the knowledge partition corresponding to the retrieved identification code is extracted.

[0059] It is worth noting that the problem unit generation module and the knowledge unit generation module have the same working mode, but are independent modules. That is, the problem unit generation module is also equipped with its own data repository to temporarily store the generated problem slices, problem semantic vectors, and problem partition / vector identification codes. Naturally, the data repository also needs to be communicatively connected with the vector pre-reading storage module to complete the interaction between information, retrieval, extraction, and other operations. The specific details belong to the prior art and will not be described here.

[0060] The context verification module adopts a "zero trust" verification strategy for the retrieval results of the vector database, that is, all retrieval results are assumed to be untrusted and need to be verified. After the retrieval process in the vector pre-reading storage module is completed using the retriever, the knowledge slices and data vectors corresponding to the result partition / vector identification code are extracted and intercepted. The context verification gateway is added in the interception state, and only the knowledge unit that passes the verification can enter the next process.

[0061] Based on the version consistency verification system for language generation described above, the present application proposes a version consistency verification method for language generation. The method is applied to a retrieval augmented generation (RAG) system, which aims to prevent data tampering and semantic poisoning attacks by introducing a versioned, auditable data integrity protection layer to ensure the consistency of generated content. The method is implemented based on a system including a versioned evidence database and a vector pre-reading storage module, and specifically includes the following steps:

[0062] S1, knowledge processing; process the original document into protected knowledge units and complete the initial trusted evidence. Specifically, the following steps are included:

[0063] S1.1, knowledge unit generation and vectorization;

[0064] A specified partitioning strategy is adopted, such as fixed-length partitioning, or more advanced partitioning strategies based on punctuation marks, paragraphs, or semantic partitioning, to divide the input original document into multiple cohesive slice data blocks C. A preset embedding model is called to generate the semantic vector V of each slice data block C in the vector space. Thus, a knowledge unit composed of (C, V) is formed.

[0065] S1.2, generating a chunk / vector identification code;

[0066] Based on the content, field attribute and technical direction of the slice data chunk C, a unique chunk / vector identification code with semantic representation ability is generated according to a preset rule. The key feature of the chunk / vector identification code is its semantic interpretability, that is, the core field and content direction of the knowledge chunk corresponding to the chunk / vector identification code can be inferred by analyzing the chunk / vector identification code itself without accessing the original data. The chunk / vector identification code will serve as the unique identifier of the knowledge unit in the entire system.

[0067] S1.3, versioned storage;

[0068] The results of the above steps are stored in a versioned credential storage database. The data records stored include: the slice data chunk C and the semantic vector V itself, the chunk / vector identification code generated for the knowledge unit, the version number, the operation timestamp and the identity information of the authorized entity performing the operation. The versioned credential storage database can be implemented by a relational database such as PostgreSQL, or by a transaction-capable NoSQL database, or by a database based on tamper-proof ledger technology under specific high security requirements.

[0069] As a preferred embodiment, after generating the chunk / vector identification code in step S1.2, the system generates a knowledge unit hash credential.

[0070] The hash value of the slice data chunk C and the hash value of the corresponding semantic vector V are calculated respectively, and the hash values of the two are combined to generate the final hash credential H(H_C||H_V) of the knowledge unit. This operation ensures the atomic association between the source text and its vector representation, and any tampering of either party will cause H to fail. When using the hash credential detection method to detect whether to trigger the security protection mechanism of the system, the final hash credential H calculated can also be stored in the versioned credential storage database.

[0071] In the present application, the operation of generating the final hash credential of the knowledge unit, that is, the combined credential operation of the hash value of the slice data chunk and the hash value of the corresponding semantic vector to generate H(H_C||H_V), the core purpose is to build a strong association in cryptography, so as to ensure the formation of an indivisible atomic association between the source text and its vector representation.

[0072] Specifically, any tampering with the original slice data block C will cause its hash value H_C to change unpredictably; similarly, any tampering with the semantic vector V, even a subtle numerical change, will make its hash value H_V completely different. Since the final credential H is calculated by combining H_C and H_V, any change in the above-mentioned hash value will directly lead to the final re-calculated hash credential and the previously stored H as the integrity benchmark cannot be matched. Thus, the system can simultaneously detect direct tampering with the text content (data poisoning) and hidden tampering with the vector representation (semantic poisoning), thereby binding the text and its vector representation as a smallest, uniformly verifiable trusted unit. It effectively blocks the possibility of contaminated data entering the subsequent generation process.

[0073] S2, build a protected search index; this stage prepares for efficient and secure search, mainly for building a vector pre-read repository;

[0074] Extract the block / vector identification code generated for all knowledge units in step S1.2 and its corresponding semantic vector V to build an independent vector pre-read repository. This module is essentially an efficient index library, and the vector pre-read repository only contains small volume data such as block / vector identification code and semantic vector V in each record, without the original slice data block C. This makes it a lightweight, retrieval-oriented "mirror" index.

[0075] S3, secure search; this stage handles user queries and completes secure search and consistency verification under the "zero trust" principle, including the following steps:

[0076] S3.1, query processing and identification code generation;

[0077] Receive user input queries. Use the same preset rules and embedded models as in S1.2 to convert user queries into one or more query vectors, and generate corresponding query block / vector identification codes for each query vector.

[0078] S3.2, perform secure search in the pre-read module;

[0079] Perform similarity search on the generated query block / vector identification code set in the vector pre-read storage module. Since the query identification code and the identification code in the library are generated based on the same rules and have consistent semantic space representation, they can quickly and accurately match to a number of candidate block / vector identification codes. Optionally, when the number of results retrieved using only the block / vector identification code is too large, the search results can also be screened again based on semantic vector similarity.

[0080] This retrieval process is completely in the independent pre-reading module, and does not directly contact the versioned certificate database containing the original knowledge content C, thereby effectively isolating the "semantic poisoning" attack on the original vector database.

[0081] S3.3, intercept the candidate set and trigger verification;

[0082] The retriever returns the Top-K most similar candidate block / vector identification codes. The system intercepts these identification codes and submits them to the context verification gateway, triggering the integrity verification process. At this time, the corresponding knowledge unit is in the "to be verified" interception state.

[0083] S3.4, context consistency verification; for each candidate block / vector identification code, the following verification steps are performed:

[0084] S3.4.1, extract the data to be verified according to the identification code: according to the candidate block / vector identification code, extract the corresponding latest version of the slice data block C, semantic vector V and the final hash certificate H stored previously from the versioned certificate database.

[0085] S3.4.2, real-time recalculation and comparison: using the same hash algorithm as S1.3, based on the extracted (C, V) real-time recalculation of its hash certificate Hc.

[0086] S3.4.3, verification decision: compare the recalculated Hc with the original H in the database. If consistent: prove that the knowledge unit has not been tampered with since the certificate, the data is complete and effective. The verification is passed. If inconsistent: prove that the knowledge unit has been tampered with (whether it is the content C or the vector V), the verification fails. The unit will be marked as abnormal and discarded, and will not be passed to the generation model.

[0087] Wherein, in the case of verification failure, the system can verify the HASH of C and V respectively to accurately identify whether the content is wrong or the vector is wrong.

[0088] S4, the security generation phase generates answers using the knowledge that passes the verification.

[0089] S4.1, build a secure context;

[0090] Combine all the slice data blocks C of the knowledge units that pass S3.4 verification, together with the user's original query to form a secure context that has passed integrity verification;

[0091] S4.2, submit this secure context to the generation model (large language model LLM), and LLM generates the final answer based on the trusted reference material.

[0092] Preferably, the system records the block / vector identification code and version number of all knowledge units used in this query. Once there is doubt about the generated results or abnormalities are found, auditors can trace the knowledge units by the block / vector identification code, verify the historical state, locate tampering behavior, etc. That is, by tracing the knowledge units, the answer generation can be accurately located to each knowledge fragment; in the versioned evidence database, all historical versions and operation records of the knowledge unit are queried to confirm whether its state is legal and has not been tampered with when answering. If the unit corresponding to the identification code fails the verification, the possible tampering source can be immediately tracked according to the "operation entity information" in the evidence record.

[0093] Therefore, this method separates the retrieval logic from the data trust logic through the block / vector identification code. That is, fast and effective retrieval is performed in the pre-reading module, which not only achieves efficient retrieval, but also ensures the integrity of the input LLM context through the "calculation, evidence storage, recalculation, and comparison" verification mechanism, solving the "data poisoning" and "semantic poisoning" risks.

[0094] In summary, the versioned consistency verification method provided by the present application fundamentally solves the data tampering and semantic poisoning risks faced by traditional RAG systems due to the lack of built-in integrity verification mechanisms. By establishing an atomic cryptographic association between the text content and vector representation of each knowledge unit, the present application constructs an active defense system that ensures any illegal tampering of the knowledge base slices or their vectorized representations is detected at both the storage layer and the application layer, thereby completely cutting off the path of contaminated data flowing to the generation model and ensuring the reliability and authenticity of the final generated answers.

[0095] Among them, the block / vector identification code is used for fast retrieval, result interception, and trace-back, which is the core technology of this technical solution. The block / vector identification code is not a simple random identification, but is generated by pre-set rules based on various semantic information such as the domain attributes, content features, and technical directions of the corresponding knowledge blocks, so that it itself has a certain degree of semantic representation ability. That is, by analyzing the identification code, the core theme and category of the corresponding knowledge block can be inferred, thereby achieving a lightweight semantic mapping.

[0096] The vector pre-reading storage module is essentially a dedicated storage library of such block / vector identification codes and their corresponding semantic vectors, and constitutes an independent retrieval index separated from the underlying knowledge base. When processing a user query, the system first adopts the same rules and models as in the knowledge processing stage to vectorize the user question, and generates one or more query block / vector identification codes accordingly. Subsequently, the retrieval operation is performed in the vector pre-reading storage module, and the most relevant candidate result identification code set is quickly located and returned by calculating the similarity between the query identification code and the identification codes in the library.

[0097] Meanwhile, in addition to the passive verification function, the present application also has strong security governance and audit traceability capabilities. The change history of all knowledge units is recorded in the versioned certificate database, so that the credibility of each retrieval result can be checked. When there is a dispute over the generated content or the system detects a verification failure, auditors can quickly and accurately locate the abnormal knowledge fragment according to the block / vector identification code, and trace its historical operation records, thereby quickly locating the source of the security incident and identifying the responsibility, and providing core support for building a new generation of RAG systems that are credible, auditable, and governable.

[0098] Of course, the present application can also have other various embodiments, and those skilled in the art can make various corresponding changes and modifications to the present application without departing from the spirit and essence of the present application. However, these corresponding changes and modifications should all belong to the protection scope of the claims attached to the present application.

Claims

1. A versioned consistency check system for language generation, characterized in that, Comprise: A knowledge unit generation module capable of segmenting text into several knowledge slices and defining semantic vectors for each knowledge slice; A knowledge unit certificate generation module capable of assigning a hash certificate to a knowledge slice; A versioned certificate storage database for storing intermediate data and result data generated in the segmentation, semantic vector definition, and certificate generation steps of the knowledge unit; The intermediate data and result data specifically include: chunk content, corresponding semantic vector, chunk / vector identification code, and hash certificate associated with chunk / vector identification code, version number, and operation entity information; An access control module for authorizing and recording data access and modification operations on the knowledge base; A vector pre-reading storage module for storing corresponding chunk identification codes of vector data; A question unit generation module for generating question slices, question semantic vectors, and question chunk / vector identification codes; A retriever for retrieving chunk / vector identification codes in the vector pre-reading storage module; Further comprising a context verification module for performing hash value verification on the knowledge slices and data vectors corresponding to the retrieved chunk / vector identification codes; The system performs the following verification steps for each candidate chunk / vector identification code: S3.4.1, extracting verification data according to identification code: according to the candidate chunk / vector identification code, extracting the corresponding latest version of slice data block C, semantic vector V, and previously stored combined certificate H from the versioned certificate storage database; S3.4.2, real-time recalculation and comparison: using the same hash algorithm as S1.3, based on the extracted C and V, real-time recalculation of the combined certificate Hc; S3.4.3, verification decision: comparing the recalculated Hc with the original H in the database; If consistent: it proves that the knowledge unit has not been tampered with since the storage, the data is complete and valid, and the verification is passed; 2. The versioned consistency check system for language generation of claim 1, wherein, If inconsistent: it proves that the knowledge unit has been tampered with, the verification fails; the unit will be marked as abnormal and discarded.

3. The versioned consistency check system for language generation of claim 1, wherein, The versioned certificate storage database is used to record the complete certificate history of each legitimate processing of each knowledge unit, and the hash of the slice data block and semantic vector of the knowledge unit is stored.

4. A method for versioned consistency checking for language generation, the method comprising: The hash certificate in the versioned certificate storage database is stored in the certificate storage database as a record with the chunk / vector identification code, version number, and operation entity information to ensure relevance. The versioned consistency verification system for language generation according to any one of claims 1-3, comprising the following logical steps: S1, knowledge processing; processing the original document into a protected knowledge unit and completing the initial trusted storage; The step S1 specifically comprises the following steps: S1.1, using a specified chunking strategy to segment the input original document into multiple cohesive slice data blocks C; calling a pre-set embedding model to generate a semantic vector V for each slice data block C in the vector space; S1.2, generating chunk / vector identification code; Generating a chunk / vector identification code with semantic representation ability based on the content, field attribute, and technical direction of the slice data block C; The chunk / vector identification code has interpretability, that is, by analyzing the chunk / vector identification code itself, the core field and content direction of the knowledge chunk corresponding to the chunk / vector identification code can be inferred without accessing the original data; S1.3, store the results of the above steps in the versioned credential evidence database; S2, build a protected search index, build a vector pre-read repository, and store small volume data content including chunk / vector identification code, semantic vector V; S3, user query, and complete secure search and consistency verification under the principle of "zero trust", including the following steps: S3.1, receive the user input query, and convert the problem into one or more query chunk / vector identification codes using the same rules as in S1.2; S3.2, perform similarity search on the generated query chunk / vector identification code set in the vector pre-read storage module; S3.3, the searcher returns the top-K most similar candidate chunk / vector identification codes; Then the system intercepts and submits it to the context verification gateway to trigger the integrity verification process; S3.4, perform context consistency verification; S4, the security generation phase generates answers using the verified knowledge.

5. The versioned consistency check method for language generation of claim 4, wherein, After step S1.2, the system generates a knowledge unit hash credential, which is: The hash value of the slice data block C and the hash value of the corresponding semantic vector V are calculated respectively, and the hash values of the two are combined to generate a combined credential H that can cryptographically strongly associate the hash value of the slice data block with the hash value of its semantic vector.

6. The versioned consistency check method for language generation of claim 4, wherein, The step S4 specifically includes the following steps: S4.1, combine all the slice data blocks C of the knowledge units that pass the S3.4 verification, together with the user's original query, to form a secure context that has passed integrity verification; S4.2, submit this secure context to the generation model to generate the final answer based on trusted reference materials.

7. The versioned consistency check method for language generation of claim 4, wherein, The system records the chunk / vector identification code and its version number of all knowledge units used in this query, thereby performing reverse lookup of the knowledge unit, verifying the historical state, and locating tampering behavior through the chunk / vector identification code.

Images