Document data verification method, electronic device, and storage medium

Abstract

The application relates to the field of computer information processing, in particular to a document data verification method, an electronic device and a storage medium, and is suitable for financial compliance, legal retrieval and enterprise knowledge base retrieval scenes. In view of the problem that the version refreshing in the existing multi-layer index storage is not synchronized, the query result is inconsistent with the state of the underlying document, and the historical result is difficult to reproduce, after receiving a query request, the application collects the version state of each layer index and related storage, constructs a unified snapshot view for this query, and completes candidate document screening, validity processing and result determination under the constraint of the view. By applying a unified version benchmark to the whole query process, the consistency of the query result and the document state is improved, the certainty of the historical result reproduction is enhanced, and the review difference and manual checking cost are reduced.

Description

Technical Field

[0001] This application relates to the field of computer information processing, and in particular to a method for verifying document data, an electronic device, and a storage medium. Background Technology

[0002] Related financial compliance, legal research, and academic evaluation systems typically employ technologies such as document management, search indexing, and source scoring to acquire, verify, and assess the credibility of cited content.

[0003] However, the citation location in the relevant schemes relies heavily on text pointers and manual parsing rules, which are not stable enough when processing cross-formats. Furthermore, there is a lack of consistent constraints between the cited content and the document version, and between the search results and the underlying storage version, making it difficult to accurately reproduce historical results. At the same time, the source scoring does not fully quantify the correlation between sources, which can easily affect the accuracy of credibility assessment.

[0004] Therefore, how to improve the certainty of citation verification and historical result reproduction, while taking into account the accuracy of information source credibility assessment, has become a technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a document data verification method, an electronic device, and a storage medium to solve the above-mentioned technical problems.

[0006] Firstly, this application provides a method for verifying document data, the method comprising:

[0007] In response to a received query request, retrieve the multi-level version status information of the multi-level index storage;

[0008] Create a transaction snapshot view based on multi-level version status information;

[0009] Based on the transaction snapshot view, determine the candidate document set;

[0010] Perform source filtering on the candidate document set to obtain valid documents, which are those that meet the preset filtering conditions;

[0011] Based on the valid documents, determine the query results corresponding to the query request.

[0012] In one possible embodiment, a transaction snapshot view is created based on multi-level version status information, including:

[0013] Based on the multi-level version status information, the consistency parameters are determined. The consistency parameters are used to indicate the document versions that the query request can read.

[0014] Determine the snapshot identifier based on the multi-level version status information;

[0015] Create a transaction snapshot view based on multi-level version status information, consistency parameters, and snapshot identifiers.

[0016] In one possible embodiment, the multi-level version status information includes a vector index segment version set, an inverted index version, a flush log sequence number, and metadata version. Based on the multi-level version status information, consistency parameters are determined, including:

[0017] For each vector index segment in the vector index segment version set, sort them in ascending order according to the version corresponding to the vector index segment to obtain the vector index segment sequence;

[0018] Based on the vector index segment sequence, the first vector index segment is determined. The first vector index segment is the first vector index segment in the sequence.

[0019] The consistency parameters are determined based on the first vector index segment, the inverted index version, the flush log sequence number, and the metadata version.

[0020] In one possible embodiment, determining the snapshot identifier based on multi-level version status information includes:

[0021] The vector index segment version set is serialized to obtain the first sequence;

[0022] Feature extraction processing is performed on the first sequence, inverted index version, disk flushing log sequence number, and metadata version to generate snapshot identifiers.

[0023] In one possible embodiment, determining the candidate document set based on the transaction snapshot view includes:

[0024] Based on the consistency parameters, perform vector index retrieval processing to obtain the first document set;

[0025] Based on the inverted index version, perform inverted index retrieval processing to obtain the second document set;

[0026] Determine the initial document set based on the first document set and the second document set;

[0027] Based on the transaction snapshot view, the initial document set is version filtered to obtain a candidate document set.

[0028] In one possible embodiment, source filtering is performed on the candidate document set to obtain valid documents, including:

[0029] The source fingerprint vector corresponding to each document in the candidate document set is determined by the independent arbitration component;

[0030] Based on the source fingerprint vector corresponding to each document, determine the source similarity matrix and average pairwise relevance of each document;

[0031] Based on the source similarity matrix and average pairwise relevance of each document, determine the equivalent number of independent sources and the reliability score of the candidate document set;

[0032] Based on the number of equivalent independent sources and reliability scores, valid documents are determined from the candidate document set using preset screening criteria.

[0033] In one possible embodiment, the equivalent number of independent sources and reliability score of the candidate document set are determined based on the source similarity matrix and average pairwise relevance of each document, including:

[0034] The independence coefficient of each document is determined based on the average pairwise correlation of each document;

[0035] Based on the independence coefficient of each document, determine the equivalent number of independent sources for the candidate document set;

[0036] The reliability score of the candidate document set is determined based on the equivalent number of independent sources.

[0037] In one possible embodiment, determining the query result corresponding to the query request based on the valid document includes:

[0038] Obtain the referenced bytecode corresponding to the valid document;

[0039] Based on the referenced bytecode, the valid document is verified to obtain the verification result;

[0040] If the verification result is that the verification fails, an evidence citation anomaly report will be generated;

[0041] If the verification result is successful, the evidence object is determined based on the valid document and the referenced bytecode;

[0042] Determine the query results corresponding to the query request based on the evidence citation anomaly report or evidence object.

[0043] Secondly, this application provides a document data verification device, the device comprising:

[0044] The acquisition module is used to respond to received query requests and retrieve the multi-level version status information of the multi-level index storage.

[0045] Create a module to create a transaction snapshot view based on multi-level version status information;

[0046] The first determination module is used to determine the candidate document set based on the transaction snapshot view;

[0047] The filtering module is used to perform source filtering on the candidate document set to obtain valid documents, which are documents that meet the preset filtering conditions.

[0048] The second determination module is used to determine the query results corresponding to the query request based on the valid documents.

[0049] In one possible embodiment, the creation module is specifically used for:

[0050] Based on the multi-level version status information, the consistency parameters are determined. The consistency parameters are used to indicate the document versions that the query request can read.

[0051] Determine the snapshot identifier based on the multi-level version status information;

[0052] Create a transaction snapshot view based on multi-level version status information, consistency parameters, and snapshot identifiers.

[0053] In one possible embodiment, the multi-level version status information includes a vector index segment version set, an inverted index version, a disk flushing log sequence number, and metadata version. The creation module is specifically used for:

[0054] For each vector index segment in the vector index segment version set, sort them in ascending order according to the version corresponding to the vector index segment to obtain the vector index segment sequence;

[0055] Based on the vector index segment sequence, the first vector index segment is determined. The first vector index segment is the first vector index segment in the sequence.

[0056] The consistency parameters are determined based on the first vector index segment, the inverted index version, the flush log sequence number, and the metadata version.

[0057] In one possible embodiment, the creation module is specifically used for:

[0058] The vector index segment version set is serialized to obtain the first sequence;

[0059] Feature extraction processing is performed on the first sequence, inverted index version, disk flushing log sequence number, and metadata version to generate snapshot identifiers.

[0060] In one possible embodiment, the first determining module is specifically used for:

[0061] Based on the consistency parameters, perform vector index retrieval processing to obtain the first document set;

[0062] Based on the inverted index version, perform inverted index retrieval processing to obtain the second document set;

[0063] Determine the initial document set based on the first document set and the second document set;

[0064] Based on the transaction snapshot view, the initial document set is version filtered to obtain a candidate document set.

[0065] In one possible embodiment, the filtering module is specifically used for:

[0066] The source fingerprint vector corresponding to each document in the candidate document set is determined by the independent arbitration component;

[0067] Based on the source fingerprint vector corresponding to each document, determine the source similarity matrix and average pairwise relevance of each document;

[0068] Based on the source similarity matrix and average pairwise relevance of each document, determine the equivalent number of independent sources and the reliability score of the candidate document set;

[0069] Based on the number of equivalent independent sources and reliability scores, valid documents are determined from the candidate document set using preset screening criteria.

[0070] In one possible embodiment, the filtering module is specifically used for:

[0071] The independence coefficient of each document is determined based on the average pairwise correlation of each document;

[0072] Based on the independence coefficient of each document, determine the equivalent number of independent sources for the candidate document set;

[0073] The reliability score of the candidate document set is determined based on the equivalent number of independent sources.

[0074] In one possible embodiment, the second determining module is specifically used for:

[0075] Obtain the referenced bytecode corresponding to the valid document;

[0076] Based on the referenced bytecode, the valid document is verified to obtain the verification result;

[0077] If the verification result is that the verification fails, an evidence citation anomaly report will be generated;

[0078] If the verification result is successful, the evidence object is determined based on the valid document and the referenced bytecode;

[0079] Determine the query results corresponding to the query request based on the evidence citation anomaly report or evidence object.

[0080] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0081] The memory stores the instructions that the computer executes;

[0082] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0083] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0084] Fifthly, this application provides a computer program product, including a computer program that, when executed by a computer, implements the method as described in any of the first aspects.

[0085] This application provides a document data verification method, electronic device, and storage medium. By responding to a received query request, it obtains multi-level version status information stored in a multi-level index and creates a transaction snapshot view based on the multi-level version status information. This enables query processing to be carried out based on a unified and definite version status, thereby improving the consistency between the retrieval results and the underlying storage version. By determining a candidate document set based on the transaction snapshot view and performing processing on the candidate document set to obtain valid documents, it is possible to complete document validity screening within a controlled version range, thereby improving the accuracy of document data verification and the stability of historical query result reproduction. Attached Figure Description

[0086] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0087] Figure 1 A schematic diagram of the structure of a document data verification system provided in this application embodiment;

[0088] Figure 2 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 1 ;

[0089] Figure 3 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 2 ;

[0090] Figure 4 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 3 ;

[0091] Figure 5 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 4 ;

[0092] Figure 6 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 5 ;

[0093] Figure 7A flowchart illustrating a document data verification method provided in this application embodiment. Figure 6 ;

[0094] Figure 8 A schematic diagram of a document data verification device provided in an embodiment of this application;

[0095] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0096] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0097] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0098] It should be noted that although the terms "first," "second," etc., are used to describe various types of information in the embodiments of this application, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. Optionally, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information.

[0099] It should be understood that the terms "comprising" or "including" indicate the presence of the previously mentioned features, steps, or operations, but do not preclude the presence, occurrence, or addition of one or more other features, steps, or operations. The terms "and / or," etc., used in this application can be interpreted as inclusive, or mean any one or any combination thereof. Optionally, "A and / or B" means "any one of the following: A; B; A and B." Additionally, the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0100] Document data verification technology is commonly used in scenarios such as financial compliance, legal retrieval, and enterprise knowledge base retrieval. Related systems typically include object storage, inverted indexes, vector indexes, and upper-level query services. After a user submits a query request, the system needs to retrieve document content, search clues, and version information from multiple types of storage, and output verifiable query results accordingly.

[0101] In related solutions, the query service typically accesses the inverted index, vector index, and document storage separately to obtain candidate documents through keyword matching, semantic recall, or metadata filtering, and then generates a result set according to sorting rules. While this type of solution can meet basic query needs in typical retrieval scenarios, its operation largely depends on the version states maintained by each storage layer, lacking a unified view constraint for a single query process.

[0102] Because the refresh rhythm, commit time, and historical version retention strategies of multi-level index storage are inconsistent, the same query initiated at different times may hit different versions of index data and document data. This can lead to situations where candidate documents have been updated but the underlying document content has not been synchronized, or the document content has changed but the index results remain in the old state. This not only makes the query results uncertain but also makes it difficult to reproduce historical results. In scenarios requiring traceability, such as compliance verification and judicial review, it can easily lead to inconsistent review conclusions, increase manual verification costs, and affect the credibility of the results.

[0103] Improving the consistency between query results and the underlying document status in a multi-level indexed storage environment, and enhancing the certainty of reproducing historical results, has become an urgent technical problem to be solved.

[0104] To address the aforementioned issues, a document data verification method is provided. Upon receiving a query request, the method first retrieves the multi-level version status information stored in the multi-level index, then creates a transaction snapshot view based on this information. Next, a candidate document set is determined using this transaction snapshot view, and processing is performed on the candidate document set to obtain valid documents, thereby determining the query result corresponding to the query request. By uniformly constraining document selection and result generation during the query process using the transaction snapshot view, the impact of multi-level version misalignment on the verification results can be reduced.

[0105] Below, in conjunction with Figure 1 An example is given to illustrate a document data validation system.

[0106] Figure 1 This is a schematic diagram of a document data verification system provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 , Figure 1 It can include snapshot adapters, independent arbitration components, and reference bytecode compilation and execution engines.

[0107] The components work together in a layered manner to complete the document version consistency verification and data source quality screening in the process of enhancing retrieval and generating questions and answers.

[0108] The snapshot adapter is a core component for version control in the system. It can interface with multi-level index storage structures, uniformly collecting multi-level version status information corresponding to vector indexes, inverted indexes, log flushing nodes, and metadata. Based on this multi-level version status information, it determines consistency parameters and unique snapshot identifiers, constructs a transactional snapshot view, and performs version visibility filtering for retrieved documents based on this view. This effectively solves the problems of inconsistent data versions and unreproducible search results under a multi-level index architecture, ensuring version consistency and stability of retrieved data.

[0109] The independence arbitration component serves as a core component for identifying the quality of data sources in the system. It can be used to perform multi-dimensional source verification on the recalled candidate document set. Specifically, this component generates source fingerprint vectors for each document, constructs a source similarity matrix, calculates the average pairwise relevance, further solves for the equivalent number of independent sources and reliability score, and filters out inferior data sources that are homogeneous, unstable, or lack independence based on the quantitative score results. This ultimately yields high-quality, effective documents, avoiding biased answers generated by large models based on fragmented and redundant reference data, and significantly improving the accuracy and credibility of the retrieved and generated question-and-answer results.

[0110] The bytecode compilation and execution engine serves as the core verification execution and result generation component of the system. It receives valid documents filtered from upstream sources and performs bytecode verification and final query result generation. Specifically, the engine first obtains the referenced bytecode corresponding to the valid document, performs compliance verification on the valid document based on the referenced bytecode, and obtains the corresponding verification result. When the verification result is a failure, an evidence citation anomaly report is automatically generated; when the verification result is a success, the compliant evidence object is determined by combining the valid document and the corresponding referenced bytecode. Finally, based on the generated evidence citation anomaly report or evidence object, the engine outputs the final query result corresponding to the user's query request, completing the overall question-and-answer verification closed loop and achieving full-process control over evidence citation compliance verification, anomaly alerts, and standardized query result output.

[0111] This application achieves end-to-end optimization from document version consistency control and efficient parallel retrieval to data source independence and optimal selection through the synergistic cooperation of the three core components mentioned above. It solves the technical defects of traditional retrieval enhancement generation technology, such as chaotic document versions, serious homogenization of data sources, and low reliability of question and answer results.

[0112] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0113] Figure 2 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 1 Please see. Figure 2 The method includes:

[0114] S201. In response to the received query request, obtain the multi-level version status information of the multi-level index storage.

[0115] Query requests can be sent to the query service node from user terminals, business systems, or audit and review platforms.

[0116] The request content may include information such as the query statement, the query scope identifier, and the time when the request was initiated.

[0117] Upon receiving a query request, the query service node accesses the multi-level index storage to obtain multi-level version status information for document data verification.

[0118] Multi-tiered index storage can include an inverted index layer, a vector index layer, an object storage layer, and a metadata storage layer associated with document records.

[0119] Each layer can provide external entities with status information such as the current commit status or the visible version boundary.

[0120] Multi-level version status information can be used to characterize the current version status of each level of the multi-level index storage, and is the basis for creating transaction snapshot views in the future.

[0121] The multi-level version status information can specifically include the vector index segment version set, the inverted index version number, the object storage flush log sequence number, the metadata version number, the version generation timestamp, and the storage instance identifier corresponding to each level.

[0122] In practice, the query service node can read the corresponding version status information from the inverted index layer, vector index layer, object storage layer, and metadata storage layer, respectively. To ensure that the status obtained in the same query reflects the multi-layer status at a unified moment, the status collection of each layer can be completed within the same request context. When there is an anomaly in the layer status acquisition or the status that does not meet the consistency requirements is not obtained, the subsequent process can be terminated or processing can continue after the preset conditions are met.

[0123] Optionally, multi-level version status information can be collected through a multi-level index status collection unit.

[0124] The multi-layer index status acquisition unit can adopt a plug-in architecture, relying on standardized adapter interfaces to connect to vector databases, inverted index engines and object storage systems from different vendors, thereby obtaining the corresponding version data.

[0125] The adapter for vector databases can be configured with the GetActiveSegment() interface. Calling this interface retrieves a set of vector index segment versions. This adapter is compatible with mainstream vector databases.

[0126] The adapter for the inverted index engine can obtain the inverted index version through the GetCheckpointVersion() interface.

[0127] The adapter for the object storage system can be configured with the GetFlushedLSN() interface to read the flush log sequence number of the object storage.

[0128] The metadata storage component is also configured with a matching adapter interface to obtain the metadata version.

[0129] After the adapters for various storage engines implement standard interfaces, they are registered in the adapter registry. When a new storage engine is connected in the future, the core logic of the snapshot adapter does not need to be changed, which effectively improves the system's scalability.

[0130] Based on the above analysis, it can be seen that by collecting the status of multi-level index storage, the version boundaries scattered in different storage components can be converged into a unified input corresponding to a single query, providing a version basis for the subsequent construction of transaction snapshot views.

[0131] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0132] S202. Create a transaction snapshot view based on the multi-level version status information.

[0133] Transaction snapshot views can be used to provide a consistent snapshot view during the processing of a query request, thereby enabling unified version isolation for multi-level index storage.

[0134] After receiving multi-level version status information, the query service node can first perform version alignment processing to identify whether there is an intersection between the states of each level that can establish a unified visible boundary.

[0135] Specifically, a snapshot boundary table can be generated based on the correspondence between the object storage flush log sequence number, the inverted index commit generation, the vector index release segment set, and the metadata version number.

[0136] The snapshot boundary table can record the visible upper bound, the invisible starting point of the next version, and the snapshot creation time for each storage layer.

[0137] In one possible embodiment, the system can select a common boundary that has been confirmed to be visible in each layer of the multi-layer version status information, and generate a transaction snapshot view based on the common boundary.

[0138] If the current state of some layers is ahead of other layers, then only the visible data range not exceeding the common boundary is extracted for the ahead layer.

[0139] If some layers have the ability to retain historical versions, it is also possible to backtrack to historical commit points that meet the common boundaries based on historical versions.

[0140] In this way, subsequent queries do not directly use the latest state of a certain layer, but instead perform retrieval using the version range defined by the same transaction snapshot view.

[0141] Based on the above analysis, this step transforms multi-level version status information into a unified version constraint that applies to the entire query process, logically binding the index layer and document layer with different refresh rhythms into the same visible range, thereby providing a basis for repeatable verification of results.

[0142] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0143] S203. Determine the candidate document set based on the transaction snapshot view.

[0144] The candidate document set can be used to take over the search and filtering results under the transaction snapshot view, specifically the set of documents to be processed that meet the version conditions specified by the transaction snapshot view.

[0145] After obtaining the transaction snapshot view, the query service node does not directly perform unconstrained retrieval on the multi-level index storage. Instead, it performs retrieval and filtering based on the version range defined by the transaction snapshot view to form an initial candidate identifier set.

[0146] The query service node performs version filtering on the initial candidate identifier set based on the transaction snapshot view. Specifically, for each document identifier, it reads the version chain corresponding to it within the snapshot boundary and determines whether the document exists simultaneously in the index records and object storage mapping records visible in the transaction snapshot view.

[0147] The candidate document set not only includes document identifiers, but can also include document version numbers, source index layers, hit methods, timestamps visible in the snapshot, and corresponding object storage reference addresses for subsequent verification processing.

[0148] To control the size of the candidate set, the system can also truncate the documents based on retrieval score, number of hit fields, or time proximity under snapshot constraints, and then perform more refined cross-layer consistency screening on the truncated documents.

[0149] Based on the above analysis, it can be seen that the candidate document set is not a simple search result, but a document set determined by multi-level index search results and version filtering rules under the constraints of transaction snapshot view. This step ensures that the documents entering the subsequent verification stage are all within the same version range, reducing the uncertainty caused by cross-level version misalignment from the source.

[0150] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0151] S204. Perform source filtering on the candidate document set to obtain valid documents.

[0152] Valid documents are those that meet the preset filtering criteria.

[0153] Valid documents can be used to represent documents that meet the requirements after processing the candidate document set, and are the direct basis for determining the query results.

[0154] The query service node performs consistency verification and content availability verification on each candidate document in the candidate document set.

[0155] First, based on the object storage reference address carried by the candidate document, the document text or text fragments visible within the transaction snapshot view boundary can be read from object storage, along with the document version metadata associated with that text, such as the text summary value, generation time, update sequence, and deletion status. Second, the document version metadata read from object storage can be compared with the version records of the candidate document in the inverted index, vector index, and metadata storage layer to determine if these records correspond to the same visible node on the same document version chain. If any layer indicates that the document has been deleted, replaced, or not yet published to the corresponding index layer within the snapshot boundary, the candidate document is deemed unqualified and removed from the candidate document set. When the version records at each layer match and the text content can be successfully read, the document enters the content screening stage.

[0156] During the content screening phase, corresponding rules are executed based on the query request type. For exact verification requests, field values, clause fragments, or hit locations that match the query statement can be extracted from the text, and their consistency with the retrieved hit information can be verified. For semantic verification requests, it can be confirmed whether candidate documents still meet the relevance requirements based on the content visible in the snapshot. For compliance review scenarios, it can also be verified whether the document permission tags, retention period tags, and case archiving identifiers are all within the snapshot's visible range.

[0157] After the above processing, candidate documents that pass the consistency verification and meet the query conditions are determined as valid documents, and a verification record is generated for each valid document. The verification record includes the document identifier, document version number, hit basis, text reference address and verification time.

[0158] If a candidate document is visible at the index level but its object storage text is unreadable within the snapshot boundary, or if the text summary value is inconsistent with the summary value registered in the index record, then the candidate document is recorded as an abnormal document and is not included in the set of valid documents.

[0159] Based on the above analysis, this step performs cross-layer verification of candidate documents using a transaction-oriented snapshot view, further converging documents that only hit at the retrieval layer into a set of documents that correspond to each other in terms of index, metadata, and text content, thereby establishing subsequent results based on the verified document facts.

[0160] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0161] S205. Based on the valid documents, determine the query results corresponding to the query request.

[0162] The query results can be returned directly from valid documents, or they can be the result of further organization, summarization, or extraction based on multiple valid documents.

[0163] After obtaining the set of valid documents, the query service node first constructs the result data structure according to the output pattern indicated in the query request. If the request is a document location query, the hit fragment, document title, version number, and text reference address are extracted from each valid document to form result entries that can be directly verified. If the request is a summary query, the content is merged based on the structured fields in the valid documents to generate summary statistics, hit lists, and source descriptions. If the request is a historical reproduction query, in addition to the content of the valid documents, the results may also include the creation time of the transaction snapshot view and multi-level version boundary summaries to support subsequent verification within the same version range.

[0164] To ensure the results are consistent with the transaction snapshot view Figure 1 Similarly, sorting, pagination, and deduplication are all performed within the valid document set, without introducing data from outside the snapshot. Sorting can be based on hit strength, semantic relevance, document timestamp, or business rule score, but the corresponding score calculation is based on the document version visible in the snapshot.

[0165] Before outputting the results, the query service node can perform an integrity check on the set of valid documents. For example, it can confirm that all document addresses referenced in the result entries are accessible, that page boundaries only cover the total number of valid documents, and that the mapping between the result summary and the original text fragments is correct. After completing the check, the system generates a query result object and returns it to the requester. At the same time, it saves the request identifier, the list of valid document identifiers, and the result summary for subsequent auditing, tracing, or replay.

[0166] Based on the above analysis, it can be seen that the process of determining the query results based on valid documents is not simply to display the search hit, but to generate verifiable and traceable result outputs on the basis of cross-layer version consistency verification. Therefore, when the same query needs to be reproduced in the future, the same result range can be reconstructed based on the saved relevant records.

[0167] This application uses a multi-layered version status information, transaction snapshot view, candidate document set, and continuous processing link between valid documents to ensure that query results and underlying document status are subject to unified snapshot constraints during a single query process, and that historical results can correspond to clear version boundaries.

[0168] It should be understood that the above examples are for illustrative purposes only and are not intended to be limiting.

[0169] This embodiment provides a document data verification method. In response to a received query request, it acquires multi-level version status information stored in a multi-level index; creates a transaction snapshot view based on the multi-level version status information; determines a candidate document set based on the transaction snapshot view; performs source filtering on the candidate document set to obtain valid documents, which are documents that meet preset filtering conditions; and determines the query result corresponding to the query request based on the valid documents. In this application, by collecting multi-level version status information stored in a multi-level index at the start of the query and generating a transaction snapshot view that is effective throughout the entire query, and then using this transaction snapshot view to uniformly constrain candidate document determination, document verification, and result output, the index data and document data used in a single query process fall within the same version boundary, thereby establishing a verifiable correspondence between the output result and the underlying document status. For problems such as misalignment between candidate hits and text content, and difficulty in reproducing historical results caused by inconsistent refresh rhythms of multi-level index storage, this application provides a specific constraint path through a snapshot processing link, ensuring that the query results have a clear version source and replay basis.

[0170] Below, in conjunction with Figure 3 The process of creating a transaction snapshot view based on multi-level version status information (202) is explained.

[0171] Figure 3 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 2 Based on the above embodiments, see also Figure 3 The method includes:

[0172] S301. Determine consistency parameters based on multi-level version status information.

[0173] Multi-level version status information includes the vector index segment version set, inverted index version, disk flush log sequence number, and metadata version.

[0174] The consistency parameter indicates which version of the document the query request can read.

[0175] Consistency parameters can reflect the common version state that can be simultaneously true among vector indexes, inverted indexes, logs, and metadata, thus providing a unified version constraint for transaction snapshot views.

[0176] After obtaining multi-level version status information, the system first extracts the set of vector index segments and sorts each vector index segment in ascending order of its corresponding version, resulting in a sequence of vector index segments. Then, the first vector index segment in the sequence is selected as the first vector index segment. Subsequently, the system performs joint matching of the first vector index segment with the inverted index version, the disk flushing log sequence number, and the metadata version, and determines consistency parameters based on the minimum boundary between their respective version numbers, version consistency rules, or preset mapping relationships.

[0177] Optionally, consistency parameters can be determined based on multi-level version status information in the following manner: sort each vector index segment in the vector index segment version set according to the ascending order of the version corresponding to the vector index segment to obtain a vector index segment sequence; determine the first vector index segment based on the vector index segment sequence; and determine the consistency parameters based on the first vector index segment, the inverted index version, the disk flushing log sequence number, and the metadata version.

[0178] The first vector index segment is the first vector index segment in the sequence of vector index segments.

[0179] In a practical implementation, after obtaining multi-level version status information, each vector index segment and its version number can be parsed from the vector index layer and then sorted in ascending order according to the version number to form a sequence of vector index segments.

[0180] Then, the first-ranked vector index segment is selected from the sequence and input together with the inverted index version, disk flushing log sequence number and metadata version into the consistency parameter calculation logic. The consistency parameter calculation logic can generate parameter values ​​corresponding to the current multi-level version state through version concatenation, comparison or hash normalization.

[0181] Inverted index versions can be used to characterize the submission status of keyword indexes.

[0182] The flush log sequence number can be used to characterize the boundary position of persistent writes.

[0183] Metadata version can be used to characterize the version status of document attributes and mapping relationships.

[0184] The inverted index version, disk flush log sequence number, metadata version, and the first vector index segment together constitute the minimum version set for consistency constraints.

[0185] During operation, the consistency parameter serves as the version anchor point for the transaction snapshot view. It is used to lock the common visibility boundary between the vector index, inverted index, flush log, and metadata, ensuring that the transaction snapshot view created subsequently based on this parameter maintains a correspondence with the multi-level version state at the time of query.

[0186] Since the first vector index segment is taken from the ordered position of the smallest version, and is used in conjunction with the other version information for calculation, the generated consistency parameter can stably reflect the alignment status between each index layer.

[0187] By adopting this approach, the consistency parameter can uniformly map the version states scattered across multiple storage layers into calculable and traceable parameter values, thereby providing a deterministic basis for the creation of transaction snapshot views and ensuring that the candidate document set obtained based on this view maintains version consistency and historical reproducibility with the query results.

[0188] Optionally, the consistency parameter may include a consistency high water level.

[0189] The consistency high water level can be calculated using the following formula:

[0190]

[0191] in, This indicates a high level of consistency. Represents the set of versions of the vector index segment. Represents vector index segment and the corresponding version number , This represents the smallest version of the vector index segment in the set of vector index segment versions. Indicates the inverted index version. This indicates the disk flush log sequence number. Indicates the metadata version.

[0192] S302. Determine the snapshot identifier based on the multi-level version status information.

[0193] After the consistency parameters are determined, a snapshot identifier can be generated based on the multi-level version status information. The snapshot identifier can be composed of a version status summary, timestamp, sequence number or a combination thereof, and is bound to the consistency parameters to ensure that the transaction snapshot view can be accurately located during subsequent access.

[0194] Optionally, the snapshot identifier can be determined based on the multi-level version status information in the following way: serialize the vector index segment version set to obtain the first sequence; perform feature extraction processing on the first sequence, the inverted index version, the disk flushing log sequence number, and the metadata version to generate the snapshot identifier.

[0195] In practical implementation, the version identifiers in the vector index segment version set can be read first and written into the serialization buffer in a preset order to form a stable first sequence. Then, the first sequence is combined with the inverted index version, the flush log sequence number, and the metadata version in the same encoding format to calculate the snapshot identifier. This snapshot identifier can be a fixed-length digest value, a reversible concatenation value, or a combination value with a check bit. The specific type can be determined according to the implementation of the storage system. In practical applications, other models of this component can also be selected, and this application does not limit this.

[0196] By adopting the above method, the first sequence can fix the state of the vector index segment version set as a reproducible input, while the snapshot identifier binds the version states of the vector index, inverted index, disk flush log and metadata in a unified manner, so that the transaction snapshot view built based on the identifier has consistent version constraints and facilitates the reproduction and verification of the same version state at different times.

[0197] Alternatively, the snapshot identifier can be determined using the following formula:

[0198]

[0199] in, Indicates the snapshot identifier. This indicates that a hash operation will be performed. This indicates that a serialization operation is being performed. Represents the set of versions of the vector index segment. Indicates the inverted index version. This indicates the disk flush log sequence number. Indicates the metadata version. The snapshot identifier indicates the moment it was created, and || represents the byte concatenation symbol.

[0200] Optionally, after determining the snapshot identifier, the snapshot identifier can be written to the persistent snapshot registry.

[0201] The snapshot registry can be configured with snapshot reference counting and lifecycle management snap-ins.

[0202] The snapshot reference count and lifecycle management unit can be used to maintain the reference count corresponding to the snapshot identifier and manage the lifecycle of the snapshot. The reference count can be represented by RC (SID).

[0203] After the snapshot identifier is generated and written to the snapshot registry, the snapshot reference count is initialized by setting RC(SID) = 1.

[0204] When a new query transaction is started and the snapshot view corresponding to the snapshot identifier is called, the reference count is incremented by 1; after the query transaction is completed, the reference count is decremented by 1.

[0205] Snapshot garbage collection requires two conditions to be met simultaneously: the snapshot's reference count is equal to 0, and the snapshot's duration exceeds a preset duration threshold.

[0206] Alternatively, the recycling criteria can be expressed by the following formula:

[0207]

[0208] Where represents the recycling criteria, and RC(SID) represents the reference count of the snapshot. Indicates the current moment. Indicates the moment when the snapshot identifier was created. This indicates the preset duration threshold.

[0209] Optionally, The default value is 86400 seconds, ensuring that the current version status can be retrieved based on the snapshot identifier within 24 hours, and the Q&A results can be reproduced afterward.

[0210] Once garbage collection is triggered when the recycling conditions are met, the corresponding record in the snapshot registry is cleared, and references to the vector index segment version set are released.

[0211] Only then can the vector index storage engine perform index segment merging operations and reclaim disk storage space.

[0212] Optionally, when the number of active snapshots in the snapshot registry exceeds a preset threshold, snapshots with version differences less than a preset number of versions can be merged.

[0213] Alternatively, the merge decision criteria for performing merge processing can be expressed by the following formula:

[0214] and

[0215] in, , This represents the version number of the vector index segment corresponding to any two snapshot identifiers. Indicates the version difference threshold. , This indicates the consistency high watermark corresponding to the two snapshot identifiers mentioned above. This indicates a preset high water level tolerance.

[0216] A brand new merged snapshot is generated, and all query transactions that originally referenced the old snapshot are redirected to the new merged snapshot. Subsequent retrieval and verification are all performed based on the merged snapshot.

[0217] S303. Create a transaction snapshot view based on multi-level version status information, consistency parameters, and snapshot identifier.

[0218] By constructing a transaction snapshot view based on multi-level version status information, consistency parameters, and snapshot identifiers, index segments, inverted records, flushed data, and metadata that conform to consistency parameters can be included in the same snapshot boundary, forming a unified view for a single query request.

[0219] Optionally, the snapshot adapter can be configured with a snapshot comparison interface.

[0220] The snapshot comparison interface can be used to determine whether transaction snapshot views corresponding to two snapshot identifiers are equivalent.

[0221] Alternatively, the following formula can be used to determine whether transaction snapshot views corresponding to two snapshot identifiers are equivalent:

[0222]

[0223] in, This indicates the snapshot equivalence determination result. This represents the snapshot identifier corresponding to the first snapshot. This indicates the snapshot identifier corresponding to the second snapshot. Indicates snapshot The corresponding system consistency high watermark, Indicates snapshot The corresponding system consistency high watermark, express The corresponding set of vector index segment versions, express The corresponding set of vector index segment versions.

[0224] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0225] This embodiment provides a document data verification method. It determines consistency parameters based on multi-level version status information, whereby the consistency parameters indicate the document versions that a query request can read. It also determines a snapshot identifier based on the multi-level version status information, and creates a transactional snapshot view based on the multi-level version status information, consistency parameters, and the snapshot identifier. The transactional snapshot view, upon creation, converges the multi-level version states to the same consistency boundary, ensuring that the index data used in the query process corresponds to the document state. Therefore, subsequent candidate document determination and result generation based on this view maintain consistent version references and improve the reproducibility and traceability of historical query results.

[0226] Below, in conjunction with Figure 4 The process of determining the candidate document set based on the transaction snapshot view is explained.

[0227] Figure 4 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 3 Based on the above embodiments, see also Figure 4 The method includes:

[0228] S401. Based on the consistency parameters, perform vector index retrieval processing to obtain the first document set.

[0229] In practice, after receiving a query request, the consistency parameters and inverted index version can be read from the multi-level index status. The consistency parameters can be determined by the version sequence of the vector index segment, the disk flushing log number, and the metadata version. Then, the query vector is input into the vector index retrieval module, and the range of searchable index segments and the visible version boundary are limited according to the consistency parameters to obtain the first document set.

[0230] S402. Based on the inverted index version, perform inverted index retrieval processing to obtain the second document set.

[0231] The second document set can be obtained by matching terms in the inverted index library based on the inverted index version.

[0232] S403. Determine the initial document set based on the first document set and the second document set.

[0233] The first and second document sets can be merged using a document identifier set merging method to form a deduplicated initial document set.

[0234] S404. Based on the transaction snapshot view, perform version filtering on the initial document set to obtain a candidate document set.

[0235] It can read the version upper bound, historical version backtracking identifier, or visibility mask in the transaction snapshot view, compare each document in the initial document set with its commit version, update version, or deletion mark, retain only documents that meet the snapshot visibility rules, and output a candidate document set.

[0236] In a specific implementation, version filtering can be jointly performed by a memory filter and index metadata. The memory filter is used to quickly determine whether a document version falls within the snapshot visibility range, while the index metadata is used to look up the version number, segment number, and commit time of a matched document. If a document has been updated after the snapshot time, it is removed; if a document has been committed before the snapshot time and has not been deleted, it is retained. Through this process, all documents in the candidate document set are consistent with the version status corresponding to the transaction snapshot view.

[0237] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0238] This embodiment provides a document data verification method. It obtains a first document set by performing vector index retrieval processing based on consistency parameters; obtains a second document set by performing inverted index retrieval processing based on the inverted index version; determines an initial document set based on the first and second document sets; and obtains a candidate document set by performing version filtering processing on the initial document set based on a transaction snapshot view. The vector retrieval results and inverted index retrieval results can be merged first, and then the filtering is completed through a unified snapshot version constraint. This ensures that the content entering the candidate document set maintains consistent visibility at the same query time, thereby improving the stability and reproducibility of the query results.

[0239] Below, in conjunction with Figure 5 The process of determining the candidate document set based on the transaction snapshot view is explained.

[0240] Figure 5 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 4 Based on the above embodiments, see also Figure 5 The method includes:

[0241] S501. Determine the source fingerprint vector corresponding to each document in the candidate document set through the independence arbitration component.

[0242] The independence arbitration component can be used to extract source metadata of candidate documents and encode the source domain name, author identifier, institution identifier, and version identifier into a source fingerprint vector.

[0243] Source fingerprint vectors can be used to characterize document source features and serve as input for subsequent relevance quantification.

[0244] The independent arbitration component can be configured with a source fingerprint vector calculation module, which can construct a three-dimensional source fingerprint vector fs for each document s. This is specifically accomplished collaboratively by the domain name hash embedding calculation unit, the author embedding calculation unit, the institution encoding calculation unit, and the fingerprint vector splicing unit.

[0245] The domain hash embedding computation unit can extract the registered domain name corresponding to the document source network address, and combine the domain top-level domain distribution, webpage ranking normalization score, and domain registration information to construct a pre-trained domain feature embedding model, outputting a 256-dimensional domain embedding vector.

[0246] The author embedding computation unit extracts fields such as author name, affiliation, and author unique identifier from the document metadata, and generates a 128-dimensional author embedding vector through the author entity embedding model; when author-related information is missing, a zero vector is used to fill in the missing information.

[0247] Furthermore, the author-embedded computational unit supports cross-language author disambiguation, resolving the issues of same-named individuals and heteronymous individuals through the following steps:

[0248] Step 1: Prioritize using the author's unique identifier as the author's unique index. If the author's unique identifier is obtained, directly read the author embedding vector already generated in the cache.

[0249] Step 2: When there is no unique author identifier, the author's name is standardized by removing honorifics, unifying pinyin, Chinese characters, and English writing format, and concatenating the hash fingerprint of the historical co-author set to generate author candidate keys;

[0250] Step 3: Search for candidate keys within the author entity database; if the matching degree is greater than or equal to 0.85, it is determined to be the same author, and the average value of the embedded vectors is calculated to complete the vector merging; if the matching degree is between 0.60 and 0.85, a manual review mark is added; if the matching degree is less than 0.60, it is determined to be different authors.

[0251] The organization coding calculation unit identifies the publishing organization from the document metadata, classifies the publishing organization into government agencies, academic institutions, enterprises, and media categories, and generates a 32-dimensional one-hot extended coding vector based on the preset organization category coding table.

[0252] The fingerprint vector concatenation unit concatenates the domain name embedding vector, author embedding vector, and organization encoding vector in sequence to obtain a 416-dimensional source fingerprint vector.

[0253] After obtaining the source fingerprint vector, it is sent to the source similarity matrix calculation module to perform similarity calculation.

[0254] When the total number of document sources supporting the current proposition exceeds 50, the source similarity matrix calculation module adopts an approximate calculation scheme, using the Locality Sensitive Hashing algorithm to divide the source fingerprint vectors into corresponding similarity buckets; precise similarity is calculated only for sources within the same similarity bucket; for sources belonging to different buckets, the default similarity value is set to 0.05; this scheme reduces the overall computational complexity; simulation experiments show that when the number of sources is 200, the error caused by approximate calculation will not exceed 2.3%, balancing computational speed and accuracy. The fingerprint vector concatenation unit can sequentially concatenate the domain name embedding vector, author embedding vector, and organization encoding vector to obtain the final source fingerprint vector.

[0255] Alternatively, the source fingerprint vector can be represented by the following formula:

[0256]

[0257] in, Indicates the source fingerprint vector, Represents the domain name embedding vector. Represents the author embedding vector. This represents the one-hot spread encoding vector. Represents a 416-dimensional real vector space. This represents the vector concatenation operation.

[0258] S502. Based on the source fingerprint vector corresponding to the document, determine the source similarity matrix and average pairwise relevance of the document.

[0259] Source similarity matrices can be used to characterize the similarity between candidate documents in terms of source fingerprints, generation paths, or citation relationships.

[0260] Average pairwise correlation can be used to summarize the average correlation level among sources in a candidate document set, thereby characterizing the degree of source duplication or homogeneous clustering.

[0261] A source similarity matrix can be constructed based on the cosine similarity, Hamming distance, or weighted matching degree between fingerprint vectors from various sources, where the matrix elements are used to represent the relevance strength between any two document sources; then, based on the source similarity matrix of each document, the relevance values ​​of each document with the remaining documents are aggregated to obtain the corresponding average pairwise relevance.

[0262] Regarding the propositions that support the same argument For each document source, the pairwise similarity between sources is calculated based on the obtained source fingerprint vectors, and a source similarity matrix is ​​constructed.

[0263] The constructed source similarity matrix belong OK -dimensional real matrix; the elements inside the matrix is the cosine similarity of the source fingerprint vectors corresponding to source p and source q, and the calculation formula is:

[0264]

[0265] wherein, , respectively represent the source fingerprint vectors corresponding to source p and source q; represents the vector dot product operation, represents calculating the modulus length of the vector.

[0266] and the diagonal elements of the matrix are set , that is, the similarity of the same source to itself is 1; the closer the calculation result is to 1, the stronger the correlation between source p and source q, and the two are most likely from the same author, the same institution or the same data set.

[0267] The average pairwise correlation can be calculated on the basis of the source similarity matrix , and the calculation formula is:

[0268]

[0269] wherein, represents the total number of document sources supporting the same assertion proposition, represents the cosine similarity between source p and source q (value range 0~1), the closer the value is to 1, the stronger the correlation between the two sources, represents traversing all pairwise distinct source combinations, accumulating the similarity of each pair of sources, p<q ensures that each pair of sources is calculated only once to avoid repeated calculation, and represents the total number of all ordered pairs among the sources; swapping p and q counts as two sets of ordered pairs.

[0270] If there is only 1 document source, that is =1, the value of the average pairwise correlation can be set to 0, that is, a single source is determined as an independent source.

[0271] S503. Determine the independence coefficient of each document according to the average pairwise correlation of each document.

[0272] The independence coefficient can be used to represent the independent contribution of a single document relative to other documents.

[0273] The average pairwise correlation can be converted into the independence coefficient according to a preset mapping relationship. The higher the average pairwise correlation, the lower the independence coefficient, and the lower the average pairwise correlation, the higher the independence coefficient.​

[0274] Alternatively, the independence coefficient can be determined using the following formula:

[0275]

[0276] in, The coefficient represents the independence, and its value ranges from (0,1). This represents the average pairwise correlation.

[0277] when The closer the value is to 1, the more independent the document sources are, and the higher the reliability of the data source. The closer a value is to 0, the stronger the correlation between document sources, the more prominent the homogeneity problem, and the more serious the source bias problem in the conclusion.

[0278] S504. Determine the equivalent number of independent sources for the candidate document set based on the independence coefficient of each document.

[0279] The equivalent independent source count can be used to represent the number of valid sources after relevance correction.

[0280] The independence coefficients of each document can be summed to obtain the equivalent number of independent sources for the candidate document set. The summation method can be either summation or weighted summation to reflect the actual independent support strength of the candidate document set after relevance correction.

[0281] Alternatively, the equivalent number of independent sources can be determined using the following formula:

[0282]

[0283] in, Indicates the equivalent number of independent sources; Indicates the source independence coefficient; The total number of document sources supporting the same assertion; This indicates the rounding operation.

[0284] The equivalent number of independent sources is affected by the correlation between sources. Less than or equal to the actual total number of sources The higher the degree of homogeneity among the various document sources, the lower the independence coefficient, and the fewer the corresponding number of equivalent independent sources; only when all sources are mutually independent can the number of equivalent independent sources equal the number of actual sources. It is used to characterize the number of actually valid independent pieces of evidence after removing redundant sources from the same source, thereby objectively measuring the overall reliability of the evidence.

[0285] S505. Determine the reliability score of the candidate document set based on the equivalent number of independent sources.

[0286] Reliability scores can be used to characterize the credibility of a candidate document set and serve as a basis for subsequent selection of valid documents.

[0287] The reliability score can be obtained by mapping the equivalent number of independent sources through a scoring function. The scoring function can be set to a piecewise mapping or a monotonically increasing mapping so that the candidate document set with a higher number of sources corresponds to a higher score.

[0288] After the candidate document set is constructed, the similarity between documents can be incorporated into the unified evaluation process. The independence of a single document can be derived by averaging the pairwise relevance, and the equivalent number of independent sources can be obtained by summing the independence. Finally, a reliability score is output so that candidate documents with high independence and high reliability can be retained as valid documents.

[0289] This processing method links the relevance between documents with the credibility of the source, ensuring that the scoring results are consistent with the true independent supporting capabilities of the candidate document set.

[0290] By adopting this approach, the credibility of the candidate document set no longer depends solely on the number of documents, but is also constrained by the correlation between documents. This can more accurately reflect the effective contributions of evidence from different sources, thereby improving the accuracy and stability of subsequent effective document screening.

[0291] Optionally, temporal stability can be obtained, and a reliability score for the candidate document set can be determined based on temporal stability and the number of equivalent independent sources.

[0292] Time stability can be assessed by relying on historical revisions from the same source to evaluate how stable the document content is over time.

[0293] Alternatively, time stability can be determined using the following formula:

[0294]

[0295] in, This indicates that the query time has been moved forward. Within the time window formed, the collection of all historical document versions corresponding to the same source; This refers to the number of historical document versions. It is the latest version of the document within the time window; , These are the keyword sets extracted from historical and latest version documents, respectively; JaccardDist represents the Jaccard distance between the keyword sets. The larger the Jaccard distance value, the greater the difference in keywords between historical and latest versions.

[0296] The value range is [0,1]; The higher the value, the less the keywords change after multiple revisions of the document, and the stronger the time stability of the document content. The lower the value, the more significant the document revisions and the more inconsistent the content.

[0297] Time window length Document half-life These are configuration parameters oriented towards the business domain.

[0298] For example, the default setting is 90 days for financial scenarios, 365 days for medical scenarios, and 180 days for legal scenarios.

[0299] After obtaining the equivalent number of independent sources and time stability Next, the overall reliability score of the candidate document set is calculated by combining the degree of source independence and the temporal stability of the document content. The higher the number of equivalent independent sources and the higher the temporal stability value, the higher the final reliability score, indicating that the conclusions drawn from this batch of documents are more credible.

[0300] Alternatively, the reliability score can be determined using the following formula:

[0301]

[0302] in, Indicates the reliability score. Indicates the equivalent number of independent sources. This represents the preset source quantity benchmark, and tanh() represents the hyperbolic tangent function. Indicates time stability.

[0303] Furthermore, confidence interval estimation is performed on the reliability. A bootstrap resampling method is used to perform K=200 resampling cycles with replacement on the source set, and the corresponding reliability is calculated after each resampling cycle. Take the 2.5th percentile of all reliability results as the lower limit of the confidence interval. The 97.5th percentile was used as the upper limit of the confidence interval. A 95% confidence interval was obtained. The corresponding calculation formula is:

[0304]

[0305] Calculate the confidence interval width The confidence interval width is used to measure the uncertainty of the reliability estimation result; when If the sample is judged to have large fluctuations, a warning of insufficient confidence will be triggered.

[0306] Optionally, the number of original sources can be obtained, the bias correction rate can be determined based on the number of original sources and the number of equivalent independent sources, and a comparison report can be generated based on the bias correction rate, the source similarity matrix, and the confidence interval.

[0307] The bias correction rate can be used to represent the proportion of false independent sources that are removed after the source independence determination.

[0308] The higher the degree of homogeneity between sources, the greater the difference between the number of equivalent independent sources and the number of original sources, and the higher the value of the bias correction rate, the more redundant documents from the same source are in the original evidence set. If the reliability of evidence is judged directly by the number of original sources, the credibility of the proposition will be overestimated.

[0309] The bias correction rate can be determined as follows:

[0310]

[0311] in, The total number of original document sources supporting the current assertion; The equivalent number of independent sources; BiasRatio is the bias correction ratio.

[0312] S506. Based on the number of equivalent independent sources and reliability score, determine the valid documents in the candidate document set through preset screening conditions.

[0313] Candidate documents can be jointly screened based on the number of equivalent independent sources and reliability scores, retaining documents with dispersed sources and reliability levels that meet the threshold conditions as valid documents.

[0314] In this process, the source fingerprint vector first transforms the document source information into a computable representation. The source similarity matrix and average pairwise relevance further quantify the degree of homology between candidate documents. The equivalent independent source count converts the relevance bias into the effective source size, and the reliability score reflects the overall credibility level of the candidate set. Thus, the system can retain documents with high independent source support in the candidate document set and output effective documents suitable for generating subsequent query results.

[0315] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0316] This embodiment provides a document data verification method that determines the source fingerprint vector corresponding to each document in a candidate document set through an independence arbitration component; determines the source similarity matrix and average pairwise relevance of each document based on the source fingerprint vector; determines the independence coefficient of each document based on the average pairwise relevance; determines the equivalent independent source number of the candidate document set based on the independence coefficient; determines the reliability score of the candidate document set based on the equivalent independent source number; and determines valid documents in the candidate document set based on the equivalent independent source number and reliability score, using preset screening conditions. The source relevance of the candidate document set can be quantified step-by-step and used for screening. The selection of valid documents no longer relies solely on a single matching result but combines source independence and reliability for judgment, thereby improving the stability and reproducibility consistency of document verification results.

[0317] Below, in conjunction with Figure 6 This section explains the process of determining the query results corresponding to a query request based on valid documents.

[0318] Figure 6 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 5 Based on the above embodiments, see also Figure 6 The method includes:

[0319] S601. Obtain the reference bytecode corresponding to the valid document.

[0320] Reference bytecode serves as a carrier for verifying and processing references to the target document. It contains the information required for subsequent processing, and its specific implementation can be a data object after encoding the reference information.

[0321] It can access the document repository to read the referenced bytecode records associated with valid documents and synchronously read the target version content of valid documents.

[0322] In one possible embodiment, the reference bytecode can be a pre-stored data object.

[0323] S602. Verify the valid document based on the referenced bytecode and obtain the verification result.

[0324] The verification result can be used to characterize the determination result of whether the valid document content matches the referenced bytecode. Its generation process is to perform constraint verification on the valid document content based on the referenced bytecode.

[0325] After parsing the referenced bytecode, the processing program can perform one or more verification processes on the valid document content based on the information recorded therein.

[0326] The system can first identify valid document content based on the association information in the referenced bytecode. After successful identification, it continues to read the reference location information in the referenced bytecode. Reference location information can include page numbers, chapter paths, paragraph indexes, anchor point identifiers, character offset ranges, table cell coordinates, or structural node paths. The processing program then locates candidate content areas within the valid document content based on the parsing results corresponding to the document format.

[0327] S603. If the verification result is that the verification fails, generate an evidence citation anomaly report.

[0328] The evidence citation anomaly report can be used to indicate citation anomalies when verification fails. It can take the form of a structured data record, an archiveable text report, or a combination of both.

[0329] After receiving the verification result, the processing program first determines the overall judgment status; when the overall judgment status is verification failure, it stops the evidence object generation process and enters the exception report generation process.

[0330] The core data in an anomaly report should include at least the target document identifier, the referenced bytecode identifier, the verification task identifier, the verification time, the failure step identifier, and the failure details.

[0331] Among them, the failure details can record the actual value and expected value of inconsistent related information, or record the target path, page number and offset of the failed location, or record the difference information between the candidate fragment of the text comparison failure and the content of the referenced bytecode record.

[0332] S604. If the verification result is successful, determine the evidence object based on the valid document and the referenced bytecode.

[0333] Evidence objects can be used to carry the referenced evidence determined after verification, and are a structured encapsulation of the verified referenced content.

[0334] After determining that the verification result is successful, the processing program combines the reference information in the referenced bytecode with the candidate areas in the valid document content that have already passed the verification to determine the final referenced segment.

[0335] The determination process includes content extraction and result object construction.

[0336] The evidence object may include at least one or more of the following: referenced content, target document identifier, target document version information, referenced bytecode identifier, content location identifier, verification pass identifier, and generation time information.

[0337] Target fragments can be extracted from valid document content based on boundary or location information recorded in the referenced bytecode. If the referenced object is text content, the text fragment is extracted according to character offset, paragraph index, or chapter node boundary; if the referenced object is table content, the table sub-region is extracted according to table number, row and column coordinates, and cell range; if the referenced object is an image, attachment, or signature area, the corresponding object or image area is extracted according to object identifier or page coordinates. After extraction, the system can associate the target fragment with relevant location information, document identifier information, and verification results to form evidence objects.

[0338] S605. Determine the query result corresponding to the query request based on the evidence citation anomaly report or evidence object.

[0339] The verifier performs hash comparison, reference fragment location, and version matching on the target content of valid documents based on the verification rules in the bytecode. If any verification item fails, the reason for failure, the abnormal location, the valid document identifier, and the query request identifier are encapsulated into an evidence citation anomaly report. If all verification items pass, the referenced content, reference location, content summary, and bytecode association information of the valid document are assembled into an evidence object. Both the evidence citation anomaly report and the evidence object are output as query results corresponding to the query request, where the former is used to indicate the unusable state of the citation, and the latter is used to indicate the verifiable evidence result.

[0340] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0341] This embodiment provides a document data verification method that obtains the reference bytecode corresponding to a valid document; verifies the valid document based on the reference bytecode to obtain a verification result; generates an evidence citation anomaly report if the verification result is a failure; determines the evidence object based on the valid document and the reference bytecode if the verification result is a success; and determines the query result corresponding to the query request based on the evidence citation anomaly report or the evidence object. In this way, by introducing reference bytecode verification before generating the query result, the output result is kept consistent with the citation validity of the valid document. Since verification failure and verification success correspond to anomaly reports and evidence objects respectively, the query request can obtain traceable and auditable result representations, thereby ensuring that the query results generated based on the valid document have clear citation basis and consistent characterization.

[0342] Below, in conjunction with Figure 7 This section provides an example to illustrate the verification process for a type of document data.

[0343] Figure 7 A flowchart illustrating a document data verification method provided in this application embodiment. Figure 6Based on the above embodiments, see also Figure 7 Suppose a compliance reviewer requests an inquiry regarding the applicable conditions of Article 35 of the Information Disclosure Measures. The entire process is collaboratively completed by a question-and-answer system, snapshot adapter, multi-level index storage, reference bytecode compilation and execution engine, independence arbitration component, and audit log library. The implementation steps are as follows:

[0344] Step 1: The question-answering system sends a request to the snapshot adapter to create a transaction snapshot corresponding to this query;

[0345] Step 2: The snapshot adapter uses a standardized adapter interface to collect multi-level version status information from the multi-level index storage;

[0346] Step 3: The snapshot adapter generates a snapshot identifier based on the collected multi-level version status information and calculates the system consistency parameters;

[0347] Step 4: The question-answering system performs semantic search and inverted index search within the view corresponding to the snapshot, obtains candidate documents after version filtering, and then sends the document source to the independence arbitration component;

[0348] Step 5: The independence arbitration component conducts source reliability assessment; first, it constructs source fingerprint vectors and completes author disambiguation; when there are many sources, it uses an approximate calculation method to obtain source similarity; then, it calculates the independence coefficient, the number of equivalent independent sources, the proposition reliability, and the bias correction rate in sequence, generates a comparison report, and sends it back to the question answering system.

[0349] Step 6: The question-and-answer system combines the filtered valid documents and uses a large model to generate preliminary conclusions, thus initiating the evidence loop verification process;

[0350] Step 7: The question-and-answer system organizes the document fragments and snapshot information of valid documents and sends them to the bytecode compilation and execution engine.

[0351] Step 8: Referencing the bytecode compilation and execution engine to perform a review and verification of valid documents in the original snapshot view;

[0352] Step 9: All valid documents have passed verification.

[0353] Step 10: The question-and-answer system organizes structured answers and feeds back the arguments, evidence, and assessment results to the compliance reviewer;

[0354] The snapshot adapter stores the snapshot number, evidence list, reliability, bias correction rate, and configuration parameters into the audit log library and generates an audit reproduction number; the result reproduction work is started after a three-month interval.

[0355] The question-and-answer system uses the original snapshot identifier to initiate the query; the snapshot adapter reverts to the previous version view and performs the search and source reliability judgment again; the search results are consistent between the two searches, and the reproduced results are updated to the audit log database.

[0356] Figure 8 This is a schematic diagram of a document data verification device provided in an embodiment of this application. Please refer to... Figure 8 The document data verification device 800 includes an acquisition module 801, a creation module 802, a first determination module 803, a filtering module 804, and a second determination module 805.

[0357] The acquisition module 801 is used to obtain the multi-level version status information of the multi-level index storage in response to the received query request;

[0358] Create module 802 to create a transaction snapshot view based on multi-level version status information;

[0359] The first determination module 803 is used to determine the candidate document set based on the transaction snapshot view;

[0360] The filtering module 804 is used to perform source filtering processing on the candidate document set to obtain valid documents. Valid documents are those that meet the preset filtering conditions.

[0361] The second determination module 805 is used to determine the query result corresponding to the query request based on the valid document.

[0362] In one possible embodiment, the creation module 802 is specifically used for:

[0363] Based on the multi-level version status information, the consistency parameters are determined. The consistency parameters are used to indicate the document versions that the query request can read.

[0364] Determine the snapshot identifier based on the multi-level version status information;

[0365] Create a transaction snapshot view based on multi-level version status information, consistency parameters, and snapshot identifiers.

[0366] In one possible embodiment, the multi-level version status information includes a vector index segment version set, an inverted index version, a disk flushing log sequence number, and metadata version. The creation module 802 is specifically used for:

[0367] For each vector index segment in the vector index segment version set, sort them in ascending order according to the version corresponding to the vector index segment to obtain the vector index segment sequence;

[0368] Based on the vector index segment sequence, the first vector index segment is determined. The first vector index segment is the first vector index segment in the sequence.

[0369] The consistency parameters are determined based on the first vector index segment, the inverted index version, the flush log sequence number, and the metadata version.

[0370] In one possible embodiment, the creation module 802 is specifically used for:

[0371] The vector index segment version set is serialized to obtain the first sequence;

[0372] Feature extraction processing is performed on the first sequence, inverted index version, disk flushing log sequence number, and metadata version to generate snapshot identifiers.

[0373] In one possible embodiment, the first determining module 803 is specifically used for:

[0374] Based on the consistency parameters, perform vector index retrieval processing to obtain the first document set;

[0375] Based on the inverted index version, perform inverted index retrieval processing to obtain the second document set;

[0376] Determine the initial document set based on the first document set and the second document set;

[0377] Based on the transaction snapshot view, the initial document set is version filtered to obtain a candidate document set.

[0378] In one possible embodiment, the filtering module 804 is specifically used for:

[0379] The source fingerprint vector corresponding to each document in the candidate document set is determined by the independent arbitration component;

[0380] Based on the source fingerprint vector corresponding to each document, determine the source similarity matrix and average pairwise relevance of each document;

[0381] Based on the source similarity matrix and average pairwise relevance of each document, determine the equivalent number of independent sources and the reliability score of the candidate document set;

[0382] Based on the number of equivalent independent sources and reliability scores, valid documents are determined from the candidate document set using preset screening criteria.

[0383] In one possible embodiment, the filtering module 804 is specifically used for:

[0384] The independence coefficient of each document is determined based on the average pairwise correlation of each document;

[0385] Based on the independence coefficient of each document, determine the equivalent number of independent sources for the candidate document set;

[0386] The reliability score of the candidate document set is determined based on the equivalent number of independent sources.

[0387] In one possible embodiment, the second determining module 805 is specifically used for:

[0388] Obtain the referenced bytecode corresponding to the valid document;

[0389] Based on the referenced bytecode, the valid document is verified to obtain the verification result;

[0390] If the verification result is that the verification fails, an evidence citation anomaly report will be generated;

[0391] If the verification result is successful, the evidence object is determined based on the valid document and the referenced bytecode;

[0392] Determine the query results corresponding to the query request based on the evidence citation anomaly report or evidence object.

[0393] This embodiment provides a document data verification device that can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effects are similar, and will not be described in detail here.

[0394] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Please refer to... Figure 9 The electronic device 900 may include: a memory 901, a processor 902, and a transceiver 903.

[0395] Memory 901 is used to store program instructions;

[0396] The processor 902 is used to execute the program instructions stored in the memory so that the electronic device 900 performs the above-described method.

[0397] Transceiver 903 may include a transmitter and / or a receiver. The transmitter may also be referred to as a transmitter, transmitter port, or transmitter interface, and the receiver may also be referred to as a receiver port, receiver interface, or similar descriptions. Exemplarily, memory 901, processor 902, and transceiver 903 are interconnected via bus 904.

[0398] This application also provides a computer program product that can be executed by a processor, and when the computer program product is executed, the above-described method can be implemented.

[0399] The document data verification device, electronic device, computer-readable storage medium, and computer program product of this application embodiment can execute the technical solutions shown in the above-described document data verification method embodiments. Their implementation principles and beneficial effects are similar and will not be repeated here.

[0400] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0401] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0402] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0403] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0404] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

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

[0406] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0407] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0408] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for verifying document data, characterized in that, The method includes: In response to a received query request, retrieve the multi-level version status information of the multi-level index storage; Based on the multi-level version status information, create a transaction snapshot view; Based on the transaction snapshot view, determine the candidate document set; The candidate document set is subjected to source filtering processing to obtain valid documents, which are documents that meet the preset filtering conditions; Based on the valid document, determine the query result corresponding to the query request.

2. The method according to claim 1, characterized in that, Based on the multi-level version status information, a transaction snapshot view is created, including: Based on the multi-level version status information, a consistency parameter is determined, which indicates the document version that the query request can read; Based on the multi-level version status information, determine the snapshot identifier; A transaction snapshot view is created based on the multi-level version status information, the consistency parameters, and the snapshot identifier.

3. The method according to claim 2, characterized in that, The multi-level version status information includes a vector index segment version set, an inverted index version, a disk flush log sequence number, and metadata version. Based on this multi-level version status information, consistency parameters are determined, including: For each vector index segment in the set of vector index segment versions, sort them in ascending order of the version corresponding to the vector index segment to obtain the vector index segment sequence; Based on the vector index segment sequence, a first vector index segment is determined, wherein the first vector index segment is the first vector index segment in the sequence. Consistency parameters are determined based on the first vector index segment, the inverted index version, the disk flushing log sequence number, and the metadata version.

4. The method according to claim 3, characterized in that, Based on the multi-level version status information, a snapshot identifier is determined, including: The set of vector index segment versions is serialized to obtain the first sequence; Feature extraction processing is performed on the first sequence, the inverted index version, the disk flushing log sequence number, and the metadata version to generate a snapshot identifier.

5. The method according to claim 3 or 4, characterized in that, Based on the transaction snapshot view, a candidate document set is determined, including: Based on the consistency parameters, perform vector index retrieval processing to obtain the first document set; Based on the inverted index version, perform inverted index retrieval processing to obtain the second document set; Determine the initial document set based on the first document set and the second document set; Based on the transaction snapshot view, the initial document set is subjected to version filtering to obtain a candidate document set.

6. The method according to any one of claims 1-4, characterized in that, The candidate document set is subjected to source filtering to obtain valid documents, including: The source fingerprint vector corresponding to each document in the candidate document set is determined by an independent arbitration component; Based on the source fingerprint vector corresponding to each document, determine the source similarity matrix and average pairwise relevance of each document; Based on the source similarity matrix and average pairwise relevance of each document, the equivalent number of independent sources and the reliability score of the candidate document set are determined. Based on the number of equivalent independent sources and the reliability score, valid documents are determined in the candidate document set using the preset filtering criteria.

7. The method according to claim 6, characterized in that, Based on the source similarity matrix and average pairwise relevance of each document, the equivalent number of independent sources and reliability score of the candidate document set are determined, including: The independence coefficient of each document is determined based on the average pairwise correlation of each document; The equivalent number of independent sources for the candidate document set is determined based on the independence coefficient of each document. The reliability score of the candidate document set is determined based on the equivalent number of independent sources.

8. The method according to any one of claims 1-4, characterized in that, Based on the valid document, determine the query results corresponding to the query request, including: Obtain the reference bytecode corresponding to the valid document; The valid document is verified based on the referenced bytecode to obtain the verification result; If the verification result is that the verification fails, an evidence citation anomaly report is generated; If the verification result is successful, the evidence object is determined based on the valid document and the referenced bytecode; Based on the evidence reference anomaly report or the evidence object, determine the query result corresponding to the query request.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

Images