A cross-document retrieval method and apparatus

Abstract

The application relates to the technical field of information retrieval, and provides a cross-document retrieval method and device, which comprises the following steps: analyzing a plurality of to-be-retrieved documents to obtain full-text content and text segment position information; dividing the text segments according to natural semantic boundaries and constructing a semantic vector index by block; constructing an entity relationship mapping index based on entities, position information and association relationships; when the query type is a semantic condition query, performing retrieval by combining the semantic vector index and the entity relationship mapping index to obtain a plurality of candidate results; and generating a retrieval result based on the plurality of candidate results. The application realizes adaptive fusion of structured accurate matching and unstructured semantic understanding, and improves the accuracy and traceability of cross-document retrieval.

Description

Technical Field

[0001] This application relates to the field of information retrieval technology, and more specifically, to a cross-document retrieval method and apparatus. Background Technology

[0002] Currently, in cross-document information retrieval scenarios, existing technologies typically employ a single retrieval paradigm: either relying on keywords or entity relationships for structured precise matching, or using semantic vectors for unstructured similarity retrieval. However, when user queries simultaneously contain explicit entity relationship intent and ambiguous semantic topics, existing systems struggle to adaptively identify query types and integrate the two retrieval capabilities, resulting in incomplete search results. Summary of the Invention

[0003] The purpose of this application is to provide a cross-document retrieval method and apparatus, which can automatically determine the query type based on the query content and integrate entity relationship mapping index and semantic vector index for collaborative retrieval, thereby improving the accuracy and traceability of cross-document information aggregation.

[0004] Firstly, a cross-document retrieval method is provided. This method may include: parsing multiple documents to be retrieved to obtain the full-text content of each document and the location information of each text segment within that full-text content; dividing the full-text content of each document into blocks according to the text segments, and constructing a semantic vector index based on the semantic vector corresponding to each text block, its document identifier, and location information; constructing an entity relationship mapping index based on each entity in the full-text content of each document, its corresponding location information, the relationship between entities, and the corresponding document identifier; when the query type of the received current query information is a semantic condition query, retrieving the current query information based on the semantic vector index and the entity relationship mapping index to obtain multiple first candidate results; and generating retrieval results based on the multiple first candidate results.

[0005] In one possible implementation, the full text content of each document is divided into blocks according to text fragments, including: Using the text fragment as the smallest indivisible unit, a sliding window method is used to combine several consecutive text fragments into a text block, wherein each text block contains a preset number of text fragments, and adjacent text blocks share a preset number of overlapping text fragments; and the document identifier corresponding to each generated text block is recorded.

[0006] In one possible implementation, adjacent text blocks share a preset number of overlapping text segments, including: dynamically determining the number of overlapping segments based on the semantic importance score of the text segments in the document, wherein the semantic importance score is calculated based on entity density or keyword weight in the text segments; for text segments with a semantic importance score higher than a first threshold, they are retained as overlapping segments in two adjacent text blocks; for text segments with a semantic importance score lower than a second threshold, they are not considered as overlapping segments, i.e., they only appear in a single text block.

[0007] In one possible implementation, after receiving the current query information input by the user, the method further includes: performing named entity recognition on the current query information to obtain entities belonging to a preset entity type in the current query information; if the number of identified entities is greater than or equal to two, then the query type of the current query information is determined to be a multi-entity relation conditional query; if the number of identified entities is less than two, then the query type of the current query information is determined to be an unstructured semantic conditional query.

[0008] In one possible implementation, based on the semantic vector index and the entity relationship mapping index, the current query information is retrieved to obtain multiple first candidate results, including: performing named entity recognition on the current query information to determine whether an entity belonging to a preset entity type is extracted from the current query information; if at least one entity is extracted, the following two retrieval paths are executed respectively: Path 1: Using the entity relationship mapping index, query all documents and text block location information containing the extracted entities to obtain the first intermediate result set; Path 2: Convert the current query information into a semantic vector, retrieve at least one text block in the semantic vector index whose similarity to the semantic vector exceeds a preset threshold, and use it as at least one second intermediate result set; take the intersection of the first intermediate result set and the second intermediate result set to obtain multiple text blocks that simultaneously contain corresponding entities and are semantically similar, and use them as multiple first candidate results; if no entity is extracted, only Path 2 is executed, and the at least one second intermediate result set is directly used as at least one first candidate result.

[0009] In one possible implementation, the method further includes: when the query type of the received query information is a multi-entity relationship condition query, performing named entity recognition on the current query information and extracting entities belonging to a preset entity type; determining a first entity and a second entity from the extracted entities, wherein the first entity and the second entity are two entities explicitly specified in the query or semantically constituting a relation pair; parsing the implicit or explicit relationship type between the first entity and the second entity from the current query information, wherein the relationship type is obtained through predefined relation vocabulary matching or through semantic role labeling; constructing a triplet query condition with the first entity as the subject entity, the relationship type, and the second entity as the object entity, and retrieving matching records in the entity relationship mapping index; wherein each record in the entity relationship mapping index contains at least a subject entity identifier, a relationship type, an object entity identifier, a source document identifier, and location information; and extracting the source document identifier and location information from all retrieved matching records as a second candidate result.

[0010] In one possible implementation, each first candidate result includes the document identifier, location information, and matching entity or entity relationship of the retrieved text block; based on the multiple first candidate results, a search result is generated, including: using the document identifier as the grouping key, aggregating all candidate results belonging to the same document into the same document group; within the same document group, sorting according to the order of appearance of the location information in the original document; for each candidate result, generating a display entry, the display entry including at least: the matching entity or entity relationship, the page number recorded in the location information, the text fragment contained in the text block, and a link to the original document; combining all document groups and their internal display entries in a preset order to generate the search result.

[0011] Secondly, a cross-document retrieval device is provided, which may include: The acquisition unit is used to parse multiple documents to be retrieved, and to obtain the full text content of each document and the position information of each text segment in the full text content; The construction unit is used to divide the full text content of each document into blocks according to text fragments, and then construct a semantic vector index based on the semantic vector corresponding to each text block, the document identifier, and the location information; and to construct an entity relationship mapping index based on each entity in the full text content of each document, the corresponding location information, the relationship between entities and the corresponding document identifier. The retrieval unit is used to retrieve the current query information based on the semantic vector index and the entity relationship mapping index when the query type of the received current query information is a semantic condition query, and obtain multiple first candidate results; The generation unit is used to generate search results based on the plurality of first candidate results.

[0012] Thirdly, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0013] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0014] This application provides a cross-document retrieval method and apparatus. The method includes parsing multiple documents to be retrieved to obtain full-text content and text segment location information; segmenting text segments according to natural semantic boundaries and constructing a semantic vector index; constructing an entity relationship mapping index based on entities, location information, and association relationships; when the query type is a semantic condition query, jointly retrieving candidate results by combining the semantic vector index and the entity relationship mapping index; and generating retrieval results based on the candidate results. This application achieves an adaptive fusion of structured exact matching and unstructured semantic understanding, improving the accuracy and traceability of cross-document retrieval. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a cross-document retrieval method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a search result structure provided in an embodiment of this application; Figure 3 A schematic diagram of the structure of a cross-document retrieval device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those with ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The terms "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but does not exclude other elements or objects. The terms "connection," "coupled," or "linked," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0018] The cross-document retrieval method provided in this application relies on a cross-document retrieval system, which may include: Document parsing module: This module parses multiple documents to be retrieved, extracting the full text content of each document and the location information of each text segment within the full text content. This module connects to the document storage unit and supports text extraction from common document formats (such as PDF, DOCX, TXT, HTML, etc.).

[0019] Semantic Vector Index Building Module: Connected to the document parsing module, it receives the parsed full-text content and location information, divides the text into blocks according to text fragments, generates semantic vectors for each text block using a pre-trained semantic coding model, and associates them with document identifiers and location information to build a semantic vector index library.

[0020] Entity Relationship Mapping Index Building Module: Connected to the document parsing module, it is used to perform named entity recognition and relation extraction on the full text content, and build an entity relationship mapping index containing entity nodes, document nodes and relation edges (which can be implemented using a graph database or a relational database).

[0021] Query parsing module: Used to receive the current query information input by the user, and to perform named entity recognition and query type determination.

[0022] The retrieval execution module calls different retrieval paths based on the query type, connects to the semantic vector index library and the entity relationship mapping index library respectively, executes the retrieval, and returns candidate results.

[0023] The sorting and context extraction module sorts the candidate results and extracts context fragments from the original document based on position information.

[0024] Results aggregation module: Groups candidate results by document and generates the final search results for display.

[0025] The modules mentioned above communicate with each other via a data bus or API interface to form a complete cross-document retrieval and processing pipeline.

[0026] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0027] Example 1 Figure 1 This is a flowchart illustrating a cross-document retrieval method provided in an embodiment of this application. The method achieves adaptive retrieval of multi-source heterogeneous documents by constructing a dual-index collaborative mechanism. For example... Figure 1 As shown, the method may include: Step S100: Parse multiple documents to be retrieved to obtain the full text content of each document and the location information of each text segment in the full text content.

[0028] Specifically, the documents to be retrieved can cover various formats such as PDF, Word, and Excel. The system extracts the plain text content by calling the corresponding parser and simultaneously records the metadata of each text segment in the original document, such as page number, chapter title, and positional information such as character offset. Unlike the fixed character length segmentation method commonly used in existing technologies, this embodiment uses natural semantic boundaries as the segmentation basis. For example, when encountering sentence-ending characters such as periods, question marks, and exclamation marks, or paragraph-ending characters such as line breaks and page breaks, they are identified as a complete semantic unit (i.e., a text segment) and segmented accordingly. That is, the full text content of each document is segmented into multiple text segments according to natural semantic boundaries. Among them, the positional information includes at least: document identifier (doc_id), page number (page), paragraph number (para_no), start character offset (start_offset), and end character offset (end_offset).

[0029] The advantage of this processing method lies in its respect for the linguistic structure of the text itself, avoiding semantic fragmentation caused by mechanical truncation, and ensuring that each subsequently generated text fragment possesses relatively independent semantic integrity. At the same time, preserving precise location information is fundamental to achieving traceability of search results, ensuring that users can easily locate the specific position of the original document when viewing search results, thereby supporting cross-validation of multi-source information.

[0030] Step S200: After dividing the full text content of each document into blocks according to the text fragments, construct a semantic vector index based on the semantic vector, the document identifier, and the location information corresponding to each text block.

[0031] Specifically, semantic vector indexing is primarily used to handle unstructured semantic matching tasks. It matches relevant content through semantic vectors, mainly describing a topic, concept, problem, or a natural language description. During construction, the text segments obtained in step S100 are first used as basic units and combined into text blocks suitable for model processing. Then, a pre-trained semantic encoding model is used to convert each text block into a high-dimensional semantic vector. This index not only stores the vector itself but also associates it with the document identifier to which the text block belongs and its position information within the original document.

[0032] It should be understood that although this embodiment primarily focuses on the functional construction of the index, the quality of the text blocks directly determines the upper limit of semantic retrieval. By segmenting based on natural semantic boundaries, semantic vectors can more accurately represent the core meaning of the text, reducing vector expression bias caused by the incorporation of noisy text. This index is particularly suitable for scenarios where users input vague topics, conceptual questions, or natural language descriptions, and can capture potential content that is semantically related but does not match the literal meaning, thus compensating for the shortcomings of traditional keyword retrieval in semantic understanding.

[0033] Step S300: Construct an entity relationship mapping index based on each entity in the full text content of each document, its corresponding location information, the relationship between entities, and the corresponding document identifier.

[0034] Specifically, the entity-relationship mapping index is a structured knowledge base that coexists with the semantic vector index. It is primarily used to handle structured conditional matching tasks, prioritizing accurate matching through the entity-relationship mapping index. The system extracts entities of preset types such as people, organizations, projects, and times, as well as the relationships between entities such as investment, employment, and cooperation, by performing named entity recognition (NER) and relation extraction on the full text of the document. Each index record contains the subject entity, object entity, relation type, and the source location of that relation in the original document.

[0035] This embodiment emphasizes the coexistence of dual indexes because, in real-world business scenarios, user search needs often combine ambiguity and precision. Semantic vector indexes excel at solving open-ended semantic questions such as "what is it?" and "how is it?", while entity relationship mapping indexes specifically address precise factual queries such as "what is the relationship between A and B?" and "who is responsible for project C?". The two are not simply a functional overlap, but rather constitute a complementary defensive depth: when semantic retrieval returns noise due to lexical ambiguity, the entity index provides precise constraints; when structured retrieval fails due to differences in expression, the semantic index provides generalized recall. This dual-track design significantly improves the system's robustness in handling complex query intents.

[0036] Step S400: When the query type of the received current query information is a semantic condition query, the current query information is retrieved based on the semantic vector index and the entity relationship mapping index to obtain multiple first candidate results.

[0037] Specifically, semantic condition queries refer to unstructured searches initiated by users without explicitly specifying multiple specific entity relationships, but rather using topics, concepts, or natural language descriptions. In this scenario, this embodiment employs a dual-index joint search strategy, rather than relying solely on semantic vectors.

[0038] The basic logic is as follows: if the query contains identifiable entities, the system first uses the entity relationship mapping index to filter out a set of documents containing these entities as a preliminary filter for the candidate range; then, the query text is converted into a semantic vector, and text blocks semantically similar to the query are retrieved from the semantic vector index; finally, the intersection of the two is taken as the first candidate result. The essence of this collaborative mechanism is to improve the signal-to-noise ratio of semantic retrieval through entity constraints, while simultaneously using semantic similarity to compensate for potential contextual gaps in entity matching. For example, when a user queries "a company's new energy layout," the system will both lock documents containing "a company" and filter out semantically highly relevant segments related to "new energy layout," thus avoiding returning documents that only mention the company but are unrelated to new energy. It should be understood that the joint retrieval described here is only a functional overview; specific optimization strategies such as dynamic weight adjustment and gradual relaxation will be detailed in subsequent embodiments.

[0039] Step S500: Generate search results based on multiple first candidate results.

[0040] Specifically, the multiple first candidate results obtained in step S400 are integrated and processed to generate the final search output for the user. Each candidate result carries the matching text block content, the document identifier, the precise location information, and the matched entity or relation tag.

[0041] In this embodiment, the generation of search results focuses on the completeness and verifiability of information, ensuring that each result can be traced back to its original source. Although this embodiment does not elaborate on the sorting and aggregation display logic of the results, it should be understood that, based on the location metadata retained in step S100 and the structured relationships extracted in step S300, the system can reorganize fragmented information scattered across different documents into ordered knowledge units, providing a reliable data foundation for users' subsequent in-depth analysis. This end-to-end location binding from low-level parsing to high-level presentation is one of the important features that distinguishes this solution from conventional vector retrieval systems.

[0042] Example 2 This embodiment, based on Embodiment 1, further optimizes the text segmentation strategy by proposing a semantically aware adaptive segmentation mechanism to address the semantic fragmentation and redundancy issues caused by traditional mechanical segmentation. Specifically, the full text content of each document is segmented according to text fragments, including: using text fragments as the smallest indivisible unit, combining several consecutive text fragments into a text block using a sliding window approach, wherein each text block contains a preset number of text fragments, and adjacent text blocks share a preset number of overlapping text fragments, which are used to preserve the complete semantic information at the boundaries of adjacent text blocks; and recording the corresponding document identifier for each generated text block, as well as the start and end positions of each text fragment in the original document, where the start and end positions both include at least the page number and character offset; and using the resulting set of segmented text blocks as the basic unit for subsequent semantic vector index construction.

[0043] Specifically, this embodiment uses the text segments obtained from natural semantic boundary segmentation in Embodiment 1 as atomic processing units, completely avoiding the risk of truncation within sentences or phrases. When assembling text blocks, the system employs a sliding window mechanism. For example, setting the window size to 5 text segments and the step size to 3 text segments automatically generates an overlapping area of ​​2 text segments between adjacent text blocks. This overlapping design is not a simple data copy, but rather a way to compensate for the attention decay problem of vector models when processing boundary information, ensuring that semantic information near the original segmentation point is fully encoded in at least one complete text block. Simultaneously, each text block is precisely bound to its physical location metadata in the original document, including the document's unique identifier, starting page number, ending page number, and character-level offset range. This fine-grained location recording is a prerequisite for accurate source tracing of search results, enabling users to directly locate specific paragraphs or even sentences in the original PDF or Word document when viewing retrieved text blocks, thereby supporting efficient information verification and cross-validation.

[0044] Furthermore, to improve the semantic quality of the chunks and optimize storage efficiency, adjacent text chunks share a preset number of overlapping text segments, including: The number of overlapping segments is dynamically determined based on the semantic importance score of each text segment in the document. The semantic importance score is calculated based on entity density or keyword weight in the text segment. semantic importance score :

[0045] in: For fragments The number of entities identified (entity types include person names, organization names, project names, etc.) is obtained through entity identification results. For fragments The number of words in the predefined keyword dictionary (the keyword dictionary can be dynamically constructed based on TF-IDF or document topics). For fragments The character length. Let be the weighting coefficient, satisfying Default value .

[0046] For text segments with a semantic importance score higher than the first threshold, they are retained as overlapping segments in two adjacent text blocks; for text segments with a semantic importance score lower than the second threshold, they are not considered overlapping segments, i.e., they only appear in a single text block.

[0047] Specifically, traditional fixed overlap strategies often indiscriminately copy all boundary text, resulting in redundant storage of numerous conjunctions, punctuation marks, or meaningless transitional sentences. This not only wastes index space but may also introduce noise that interferes with vector representation. This embodiment introduces a semantic importance assessment mechanism, quantifying the information value of a text segment by calculating the entity density (e.g., the ratio of named entities to the total number of words) or the TF-IDF weight of core keywords. For example, if a text segment contains multiple high-density entities such as "XX Technology," "Semiconductor," and "Investment Amount," its semantic importance score will be determined to be higher than the first threshold, and the system will force it to be included in the overlap area, ensuring that this key information is fully preserved in the vector representations of both preceding and following text blocks. Conversely, if a text segment contains only low-information content such as "In summary" or "Specifically as follows," its score will be lower than the second threshold, and the system will cancel the sharing of this segment, assigning it only to the current text block. This dynamic adjustment mechanism achieves an adaptive balance of "multiple protections for important information and simplified storage of secondary information," significantly reducing the construction cost and query latency of the semantic vector index while ensuring retrieval recall.

[0048] In addition, to prevent semantically unrelated text from being forcibly combined, before using a sliding window method to combine several consecutive text segments into a single text block, the following steps are also included: The semantic coherence between text segments is identified. Semantic coherence is obtained by calculating the cosine similarity of the TF-IDF vectors of words in adjacent text segments or by using a pre-trained sentence similarity model. When the semantic coherence between two adjacent text segments is lower than a preset threshold, a block boundary is forcibly set between them to prevent the two text segments from being combined into the same text block.

[0049] Specifically, even if text fragments are physically adjacent, their semantic content may be fragmented, such as the boundary between the "Company Financial Status" section and the "Technology R&D Progress" section in a document. Relying solely on the mechanical rules of the sliding window can easily merge these two unrelated sections into a single text block, resulting in a semantic vector that neither accurately represents financial information nor clearly reflects R&D content, creating so-called "semantic noise." This embodiment adds a semantic coherence detection step before block formation. It quantifies the degree of association between adjacent fragments by calculating the cosine similarity of their TF-IDF vectors or by using models such as Sentence-BERT to assess semantic distance. When the similarity is detected to be below a preset threshold (e.g., an empirical value between 0.3 and 0.5), the system ignores the length limit of the sliding window and directly inserts a forced separator between the two, ensuring high semantic cohesion within the newly generated text block. This mechanism effectively overcomes the technical bias of existing technologies that focus only on the number of characters while ignoring semantic structure, allowing each text block to participate in subsequent vector retrieval as a pure semantic unit, significantly improving the accuracy and robustness of cross-document retrieval in complex document layouts. It should be understood that the specific values ​​of the above thresholds can be adjusted adaptively according to the document type and business scenario. For example, in legal contract scenarios, the threshold can be appropriately increased to ensure the independence of the clauses, while in news narrative documents, the threshold can be appropriately decreased to maintain the continuity of the narrative.

[0050] Example 3 This embodiment, based on Embodiment 1, further refines the specific implementation logic of the query parsing stage and proposes an adaptive query type determination mechanism based on the number of entities. Specifically, after receiving the current query information input by the user, the method further includes: Named entity recognition is performed on the current query information to obtain entities in the current query information that belong to a preset entity type. The preset entity type can include at least one or more of the following: people, organizations, projects, events, and time. If the number of identified entities is greater than or equal to two, the query type for the current query information is determined to be a multi-entity relation conditional query; if the number of identified entities is less than two, the query type for the current query information is determined to be an unstructured semantic conditional query.

[0051] Specifically, the predefined entity types are not arbitrarily selected, but rather determined based on high-frequency carriers of knowledge association in cross-document retrieval scenarios. People, organizations, projects, events, and time constitute the core framework of business fact descriptions, and the vast majority of valuable cross-document clues rely on the interactions between these entities. In terms of identification methods, a hybrid extraction approach combining a pre-trained named entity recognition model with a domain-specific dictionary can be used to ensure coverage of both general and business-specific entities. For example, in a financial due diligence scenario, "semiconductor" might be identified as a technical term by a general model, but by loading an industry dictionary, it can be corrected to an entity of the "industry / track" type, thus being included in subsequent counting and matching logic. This targeted entity type definition provides high-quality structured feature input for subsequent query classification, avoiding misjudgments of query intent due to entity omissions or misidentifications.

[0052] The underlying logic of the judgment rules, using "two entities" as the threshold for distinguishing between multi-entity relational queries and semantic conditional queries, is determined by the minimum topological structure of "relationships" in the knowledge graph. Any explicit or implicit binary relation requires at least one subject and one object to be valid. When a query contains two or more predefined entities, the user's intent is highly likely to point to specific factual associations between these entities. In this case, enabling structured matching paths can directly hit the precise answer. Conversely, when a query contains only one entity or even no entity, the user is more likely seeking an overview, background, or divergent information around the topic. In this case, semantic vector retrieval is better able to capture ambiguous intents. For example, when a user enters "Zhang San's project," only the entity "Zhang San" is identified. Although the word "project" appears literally, it does not point to a specific project name, so it is judged as a semantic conditional query. The system will retrieve all text blocks related to Zhang San and semantically involving project content. However, when a user enters "Zhang San and Li Si's project," the system identifies two entities, "Zhang San" and "Li Si," satisfying the minimum condition for relationship construction. Therefore, it is automatically routed to the multi-entity relationship conditional query path, directly retrieving records of projects in which the two participated from the entity relationship mapping index. This hard-segmentation rule based on quantity concisely and efficiently achieves binary splitting of query intent, avoiding the inference delays and uncertainties brought about by complex intent classification models.

[0053] It should be understood that the above determination process is fully automated, requiring no manual selection of options such as "exact match" or "fuzzy search" by the user on the search interface. In traditional retrieval systems, users often need professional knowledge to correctly select the search mode; otherwise, mismatched modes can easily lead to poor results. This application integrates this decision-making logic into the backend parsing stage, enabling the system to adaptively match the optimal search strategy based on the objective characteristics of the user's natural language input. This not only lowers the user's operational threshold and cognitive load but, more importantly, eliminates the risk of retrieval failure caused by human error. Furthermore, this adaptive determination step forms the cornerstone for triggering subsequent differentiated retrieval processes: only after accurately determining the type can the system correctly invoke advanced strategies such as dual-path fusion retrieval or triple exact matching in subsequent steps, thereby ensuring the robustness and accuracy of the entire cross-document retrieval chain under various query qualities.

[0054] Example 4 Based on step S400 of Example 1 and determining the query type as a semantic condition query in Example 3, the specific implementation logic for retrieving the current query information based on the semantic vector index and the entity relationship mapping index is described in detail here.

[0055] Specifically, based on semantic vector index and entity relationship mapping index, the current query information is retrieved to obtain multiple first candidate results, including: named entity recognition of the current query information to determine whether an entity belonging to a preset entity type is extracted from the current query information; If at least one entity is retrieved, the following two search paths will be executed respectively: Path 1: Utilize the entity relationship mapping index to query all documents and text block location information containing the extracted entity, and obtain the first intermediate result set; Path 2: Convert the current query information into a semantic vector, retrieve at least one text block in the semantic vector index whose similarity to the semantic vector exceeds a preset threshold, and use it as at least one second intermediate result set; take the intersection of the first intermediate result set and the second intermediate result set to obtain multiple text blocks that simultaneously contain the corresponding entities and are semantically similar, and use them as multiple first candidate results. If no entity is extracted, then only path two above is executed, and at least one second intermediate result set is directly used as at least one first candidate result.

[0056] Specifically, this dual-path fusion retrieval strategy aims to address the limitations of single-search modes under semantic condition queries. Path 1 leverages the structured characteristics of entity relation mapping indexes to quickly locate document ranges containing key entities, acting as a "hard constraint" filter to effectively eliminate noisy results that, while semantically similar, lack factual basis. Path 2 utilizes the unstructured understanding capabilities of semantic vector indexes to capture themes, concepts, and contextual information within the query intent, compensating for potential omissions of synonymous expressions or implicit related information by simple entity matching. The intersection of these two paths is not a simple logical superposition but a dynamic balancing mechanism: ensuring both the factual accuracy of the results (the presence of entities) and the semantic relevance of the content (similarity). For example, when a user queries "a company's new energy battery technology roadmap," semantic retrieval alone might return numerous industry reviews mentioning "new energy" but unrelated to the company, or excerpts from annual reports discussing traditional fuel vehicle business; however, through the intersection of the two paths, the system can accurately pinpoint text blocks that both contain the entity "a company" and are semantically highly focused on "new energy battery technology." Furthermore, when named entity recognition fails to extract any preset type of entity (e.g., when the user inputs a purely conceptual question "What is deep learning"), the system automatically switches to a pure semantic retrieval path to ensure that the retrieval service is not interrupted due to missing entities, demonstrating the solution's fallback and fault tolerance capabilities.

[0057] Furthermore, to address the potential "hard intersection" zero-result problem that may occur when multiple entities co-occur in Path 1, this embodiment introduces a progressive relaxation mechanism. Specifically, Path 1 utilizes the entity relation mapping index to query all documents and text block location information containing the extracted entities, including: when multiple entities are extracted, querying the document identifier set corresponding to each entity in the entity relation mapping index and calculating the intersection of each document identifier; retaining only the documents and text block location information that simultaneously contain all extracted entities as the first intermediate result set; if the number of documents simultaneously containing all extracted entities is zero, the restriction is gradually relaxed, retaining documents containing at least N-1, N-2, ... entities in sequence, until a non-empty first intermediate result set is obtained, where N is the total number of extracted entities.

[0058] Specifically, in real-world cross-document retrieval scenarios, user queries often contain numerous limiting conditions, while the information distribution in the document database may exhibit sparsity or incompleteness. Strictly performing full entity intersection matching can easily lead to empty results due to a minor entity not being indexed or having differing representations, severely impacting user experience.

[0059] The Nx fallback mechanism designed in this embodiment is essentially an automated constraint relaxation strategy. When the system detects that the exact intersection of N entities is empty, it does not immediately abandon the structured constraints and switch to pure semantic retrieval. Instead, it attempts to retain the intersection of N-1 entities, prioritizing the discarding of entities with lower frequency or lower weight in the query, thereby restoring recall capability while maintaining the highest possible strength of the structured constraints. For example, suppose a user query contains three entities: "Company A," "Project B," and "Manager C" (N=3). The system does not find any documents containing all three in the entity relationship mapping index. In this case, the system automatically downgrades to searching for document sets containing any two entities (such as "Company A + Project B" or "Company A + Manager C"). If there are still no results, it continues to downgrade to single-entity matching. This process is entirely triggered and executed automatically by the backend algorithm. Frontend users do not need to manually modify query terms or adjust filtering conditions, achieving a seamless experience of "constant query intent and adaptive retrieval strategy." It should be understood that this gradual relaxation is not a disorderly degradation, but rather a smooth transition between structured exact matching and semantic fuzzy retrieval. This allows the system to return the most relevant candidate results even when faced with missing data or excessive user constraints, significantly improving the robustness and practicality of the cross-document retrieval system.

[0060] Example 5 Based on Example 3, which determines that the query type of the current query information is a multi-entity relationship condition query, this embodiment further details the precise matching process and multiple fault tolerance mechanisms for this type of query.

[0061] Specifically, when the query type of the received query information is a multi-entity condition query, named entity recognition is performed on the current query information to extract entities that belong to the preset entity type; from the extracted entities, the first entity and the second entity are determined, and the first entity and the second entity are two entities that are explicitly specified in the query or that constitute a relation pair semantically; The implicit or explicit relationship type between the first entity and the second entity is parsed from the current query information. The relationship type is obtained through matching a predefined relation lexicon or through semantic role annotation. A triple query condition is constructed with the first entity as the subject entity, the relationship type, and the second entity as the object entity. Matching records are retrieved from the entity relationship mapping index. Each record in the entity relationship mapping index contains at least the subject entity identifier, the relationship type, the object entity identifier, the source document identifier, and the location information. The source document identifier and location information from all retrieved matching records are extracted as the second candidate results.

[0062] Specifically, the core of multi-entity relation conditional queries lies in capturing definite factual connections between entities, rather than fuzzy semantic similarities. This embodiment uses a subject-relationship-object triple structure as the basic atomic unit for retrieval. This structured expression naturally fits the storage paradigm of knowledge graphs and relational databases, enabling accurate hits with O(1) or O(logN) complexity, avoiding the inevitable accuracy loss when vector retrieval performs approximate nearest neighbor searches in high-dimensional spaces. For example, when a user inputs "Company A acquired Factory B", the system identifies the first entity "Company A", the second entity "Factory B", and the relation type "acquisition", and then directly searches for records that satisfy the triple constraint in the entity relation mapping index. Once a match is found, the system not only returns the matching document ID, but also accurately extracts the page number and character offset of the relation in the original document, allowing the user to directly jump to the original source of the factual statement for verification.

[0063] This precise matching mechanism based on structured indexes provides far greater reliability and efficiency than pure semantic retrieval when dealing with business scenarios that require extremely high accuracy, such as legal compliance review and supply chain relationship tracing.

[0064] However, in practical applications, users' natural language input often contains missing or non-standard relational expressions, leading to the failure of triple construction. Therefore, this embodiment introduces an adaptive degradation mechanism based on confidence assessment. Specifically: After determining the query type of the current query information, the process also includes: when the query type is determined to be a multi-entity relationship conditional query, further determining whether there are explicit relational terms between the extracted multiple entities; if there are no explicit relational terms, then calling the pre-trained semantic role labeling model to predict the implicit relationship type between the subject entity and the object entity from the query information, and generating the corresponding relationship confidence score; if the relationship confidence score is lower than the preset confidence threshold, then automatically downgrading the query type to an unstructured semantic conditional query, and processing it according to the retrieval path of the semantic conditional query.

[0065] Specifically, semantic role labeling models can analyze the deep semantic relationships between predicates and arguments in a sentence. Even if standard relational words such as "investment" or "appointment" do not appear in the original text, the potential association type can be inferred from the context. For example, if a user inputs "Company A, Project B, 2023," although there is a lack of explicit verbs, the model may predict relationships such as "participation" or "responsibility" based on domain knowledge. However, such predictions are probabilistic. If low-confidence predictions are blindly accepted for structured matching, it is easy to cause missed or false detections. Therefore, this embodiment sets a confidence threshold as a safety valve. When the prediction score is lower than this threshold (e.g., an empirical value between 0.6 and 0.8), the system determines that the current structured matching risk is too high and automatically triggers a degradation strategy, seamlessly switching the query to the semantic condition query path described in Embodiment 4. The essence of this mechanism is to establish a dynamic balance between "precise but fragile" structured retrieval and "fuzzy but robust" semantic retrieval, ensuring that the system can always provide usable search results when faced with fluctuations in the quality of user input, rather than returning empty pages or incorrect answers, thus significantly improving the system's fault tolerance and the continuity of user experience.

[0066] Even if the triple is successfully constructed and the confidence level meets the requirements, the search may still fail due to inconsistencies between the relationship direction recorded in the index and the user's query, or mismatches in entity granularity. To address this issue, this embodiment further constructs a double-layered defense of role swapping and higher-level generalization. Specifically, after constructing the triple query condition with the first entity as the subject entity, the relationship type, and the second entity as the object entity, the following steps are also included: if no matching record is found in the entity relationship mapping index, the roles of the first entity and the second entity are automatically swapped, i.e., the second entity is used as the subject and the first entity as the object for a second search; if no match is still found, the entity hierarchy recorded in the entity relationship mapping index is further utilized to replace the first entity or the second entity with its higher-level entity and the search is repeated, and the replacement path is recorded as explanatory information and added to the search results.

[0067] Specifically, relational orientation fault tolerance solves the matching challenges arising from the conversion between active and passive voice in natural language. For example, a user queries "A is responsible for B," but the index might only store records for "B belongs to A." In this case, simple triple matching would fail, but subject-object swapping would result in a successful match. Superordinate entity generalization solves the problem of granularity mismatch between concrete instances and abstract concepts. For example, a user queries "contracts signed by Zhang San," but the index might only record "contracts signed by the project manager" without a specific name, or only "contracts signed by personnel." In this case, the system backtracks "Zhang San" up the entity hierarchy tree, replacing it with superordinate concepts such as "project manager" or "personnel" for retrying. More importantly, whether it's role swapping or superordinate generalization, the system explicitly appends this replacement process as explanatory information to the search results, such as prompting "No direct record found for 'Zhang San,' we have expanded the search to include contracts related to 'project manager.'" This transparent feedback mechanism not only eliminates users' doubts about the source of search results and enhances the system's credibility, but also transforms generalized results that might otherwise be considered "inaccurate" into valuable clues for knowledge discovery, helping users understand the potential relationships between data. It should be understood that the aforementioned triple fault-tolerance mechanisms (confidence downgrading, role reversal, and higher-level generalization) constitute a progressively deeper defense. They are not executed in isolation, but are dynamically triggered based on search feedback, collectively ensuring the recall rate and usability of multi-entity relationship queries in complex real-world data environments.

[0068] Furthermore, after obtaining the second candidate result, this embodiment can further utilize the location information recorded in step S100 to perform contextual verification and noise filtering on the second candidate result, so as to improve the accuracy of the final retrieval result.

[0069] Specifically, for each matching record in the entity relationship mapping index, the system extracts the position information (including their respective page numbers and character offsets) of the subject entity and object entity in the original document, and calculates the actual distance between the two entities in the original document. If the difference in character offsets between the two entities in the original document exceeds a preset distance threshold, or if the two entities are located in non-adjacent chapters or paragraphs in the original document (i.e., their page numbers are not adjacent), the system determines that the matching record is low-confidence noise and filters it, or reduces its ranking weight in the final search results.

[0070] The underlying technology is as follows: In cross-document retrieval scenarios, the same long document may mention multiple entities in different chapters. Although these entities may co-occur at the document level, they actually exist in completely different contexts and have no real semantic relationship with each other. For example, an annual report might mention "Company A" as a partner on page 3 and "Factory B" as a competitor on page 87. Although the entity relationship mapping index may contain records of "Company A—Partner—Factory B" (from other documents), if the two entities in the documents pointed to by this record are far apart and belong to different chapters, then this record is likely noise. By introducing a location-distance-based filtering mechanism, the system can improve retrieval accuracy from the document level to the paragraph level, effectively eliminating mismatches caused by accidental co-occurrence of entities in long documents.

[0071] Furthermore, the system combines the text block boundary information recorded in step S200 to further verify whether the two entities in the matching record are located within the same text block or adjacent text blocks. If the two entities are located in non-adjacent text blocks, the system marks the record as a weak association and adds distance hints to the final search results to help users judge the credibility of the association themselves. This refined filtering strategy based on location information, together with the aforementioned triple fault tolerance mechanism, forms a synergistic effect of "expanding first and then filtering"—the fault tolerance mechanism is responsible for expanding the recall scope as much as possible to avoid omissions, while location filtering is responsible for removing context-irrelevant noise from the recall results. The combination of the two enables multi-entity relationship queries to achieve high precision while maintaining a high recall rate.

[0072] In summary, the complete processing flow of the multi-entity relationship condition query described in this embodiment can be summarized as follows: After receiving the query information input by the user, the system first confirms that the query information contains at least two preset types of entities through the named entity recognition and quantity determination mechanism described in Embodiment 3, thereby identifying it as a multi-entity relationship condition query; subsequently, the system extracts the first entity and the second entity from the query, and parses the relationship type between the two through relational vocabulary matching or semantic role labeling, constructing a subject-relationship-object triple query condition; then, it performs an exact match on the entity relationship mapping index using this triple, if the first match is successful... If a match is not found, the retry mechanism of subject-object swapping and superordinate entity generalization is triggered sequentially, and the replacement path is recorded as explanatory information in each round of retry. If the confidence of the relation type is insufficient, it is automatically downgraded to the semantic condition query path described in Example 4, and the dual-index joint retrieval ensures fallback recall. After obtaining the matching record, the system uses the above-mentioned context verification and noise filtering mechanism based on location information to eliminate low-quality matches with excessively large entity spacing or irrelevant context. Finally, the filtered second candidate results are processed through document identifier aggregation, position sorting, and display item generation to output structured search results containing accurate source information.

[0073] Example 6 This embodiment, based on step S500 of Embodiment 1, further details the mechanism for generating and presenting search results. Specifically, each first candidate result includes the document identifier, location information, and matching entity or entity relationship of the retrieved text block. This data is not generated temporarily, but directly inherited from the document parsing metadata of step S100 and the block record of step S200 in Embodiment 1, ensuring that each search result has a precise physical traceability basis. Based on this, the process of generating search results from multiple first candidate results includes: Using document identifiers as grouping keys, all candidate results belonging to the same document are aggregated into the same document group. Within each document group, the candidate results are sorted according to their order of appearance in the original document. For each candidate result, a display entry is generated, which can include at least: the matching entity or entity relationship, the page number recorded in the location information, the text fragment contained in the text block, and a link to the original document. All document groups and their display entries are combined in a preset order to generate search results. For example, a schematic diagram of the search result structure using the document identifiers "2023_Annual Report.pdf" and "Meeting Proceedings_2024.docx" as grouping keys is shown below. Figure 2 As shown.

[0074] Specifically, this document-identification-based aggregation strategy aims to address the cognitive discontinuity caused by information fragmentation in cross-document retrieval. In traditional list-style search results, multiple matching records from the same document are often scattered and interspersed with results from other documents, making it difficult for users to perceive the logical connections between these fragments in their original context. This embodiment, by grouping all candidate results under the same document into the same group, effectively reconstructs the knowledge container of the original document at the retrieval result level. For example, when a user matches three fragments simultaneously—"revenue data," "risk warning," and "strategic planning"—in an annual report, the system will aggregate and display these three, allowing the user to intuitively see the full picture of the document's connection to the query intent across different dimensions, rather than examining individual fragments in isolation. This aggregation method significantly improves the efficiency of users cross-validating multi-source information, because multiple matches within the same document often constitute a complete chain of mutually corroborating evidence.

[0075] Furthermore, within the same document group, the documents are strictly sorted according to the original order of appearance indicated by the location information. This is not merely a restoration of physical location, but also a reconstruction of reading logic and narrative flow. Since the starting page number and character offset of each text block were accurately recorded in Example 1, the system can seamlessly re-embed discrete search results into the linear narrative flow of the original document. For example, if a contract document contains three matching segments—"Party A's Definition," "Payment Terms," ​​and "Liability for Breach of Contract"—the system will display them in this order, rather than according to semantic similarity. This design respects the original document's creation logic, avoids contextual confusion caused by algorithmic rearrangement, and provides users with a coherent experience close to reading the original text when reviewing search results. This is particularly important for scenarios heavily reliant on context, such as legal compliance reviews and technical document reading.

[0076] The core design element of the displayed items is to balance information density and ease of verification. Matching entities or entity relationships provide a structured summary of facts, helping users quickly determine the relevance of the results; the page numbers recorded in the location information provide users with physical coordinates; the text fragments contained in the text block display the specific context, compensating for details that might be lost in the structured summary; and the link to the original document is the key interactive component for achieving closed-loop verification. In its implementation, this link not only points to the document file itself but also carries precise anchor parameters (such as page numbers or character offsets), allowing users to directly jump to the target paragraph and highlight it in a PDF reader or document editor after clicking, without needing to manually flip through pages.

[0077] This seamless connection between search results and the original text greatly reduces the operational costs of information verification and enhances the practical value of the technical solution in actual business operations.

[0078] Furthermore, all document groups and their internal display items are grouped in a preset order, which can be flexibly configured according to specific application scenarios. For example, in time-sensitive scenarios, document groups with more recent publication dates can be displayed first; in relevance-priority scenarios, groups can be sorted in descending order based on the average semantic similarity or entity matching confidence of candidate results within the document; and in due diligence scenarios, they can also be sorted according to the authority level of the document source.

[0079] It should be understood that although this embodiment uses document-level aggregation as the main presentation format, in other implementations, it can also be switched to a pure timeline view or an entity relationship graph view according to user needs. As long as the underlying data retains complete document identifiers and location metadata, it can support flexible expansion of various upper-level visualization forms. This decoupling design of the data and presentation layers further enhances the adaptability of this application to different business scenarios.

[0080] It should be understood that although this embodiment uses the financial field as a specific application scenario, the technical solution of this application is not limited to this, and is also applicable to any field that requires cross-validation and knowledge aggregation of multi-source heterogeneous documents, such as legal document review, medical record analysis, and scientific research project application.

[0081] Corresponding to the above method, embodiments of this application also provide a cross-document retrieval device, such as... Figure 3 As shown, the device includes: The acquisition unit 310 is used to parse multiple documents to be retrieved and obtain the full text content of each document and the position information of each text segment in the full text content; The construction unit 320 is used to divide the full text content of each document into blocks according to text fragments, and then construct a semantic vector index based on the semantic vector, document identifier, and location information corresponding to each text block; and to construct an entity relationship mapping index based on each entity in the full text content of each document, the corresponding location information, the relationship between entities and the corresponding document identifier. The retrieval unit 330 is used to retrieve the current query information based on the semantic vector index and the entity relationship mapping index when the query type of the received current query information is a semantic condition query, and obtain multiple first candidate results; The generation unit 340 is used to generate search results based on the plurality of first candidate results.

[0082] The functions of each functional unit of the cross-document retrieval device provided in the above embodiments of this application can be implemented through the above method steps. Therefore, the specific working process and beneficial effects of each unit in the cross-document retrieval device provided in the embodiments of this application will not be repeated here.

[0083] This application also provides an electronic device, such as... Figure 4 As shown, it includes a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440.

[0084] Memory 430 is used to store computer programs; When the processor 410 executes the program stored in the memory 430, it performs the following steps: The system parses multiple documents to be retrieved, obtaining the full text content of each document and the location information of each text segment within that full text content; After dividing the full text content of each document into blocks according to text fragments, a semantic vector index is constructed based on the semantic vector corresponding to each text block, the document identifier to which it belongs, and the location information. Based on the entities, their corresponding location information, the relationships between entities, and the corresponding document identifiers in the full text content of each document, an entity relationship mapping index is constructed. When the query type of the received current query information is a semantic condition query, the current query information is retrieved based on the semantic vector index and the entity relationship mapping index to obtain multiple first candidate results; based on the multiple first candidate results, a search result is generated.

[0085] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0086] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0087] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0088] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0089] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 1 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0090] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the cross-document retrieval methods described in the above embodiments.

[0091] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the cross-document retrieval methods described in the above embodiments.

[0092] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

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

Claims

1. A cross-document retrieval method, characterized in that, The method includes: The system parses multiple documents to be retrieved, obtaining the full text content of each document and the location information of each text segment within that full text content; After dividing the full text content of each document into blocks according to text fragments, a semantic vector index is constructed based on the semantic vector, document identifier, and location information corresponding to each text block; an entity relationship mapping index is constructed based on each entity in the full text content of each document, its corresponding location information, the relationships between entities, and the corresponding document identifier; when the query type of the received current query information is a semantic condition query, the current query information is retrieved based on the semantic vector index and the entity relationship mapping index, resulting in multiple first candidate results; based on the multiple first candidate results, the search results are generated; among them, obtaining multiple first candidate results includes: performing named entity recognition on the current query information to determine whether an entity belonging to a preset entity type is extracted from the current query information; if at least one entity is extracted, the following two search paths are executed respectively: Path 1: Utilize the entity relationship mapping index to query all documents and text block location information containing the extracted entity to obtain the first intermediate result set; Path 2: Convert the current query information into a semantic vector, and retrieve at least one text block in the semantic vector index whose similarity to the semantic vector exceeds a preset threshold, as at least one second intermediate result set. The intersection of the first intermediate result set and the second intermediate result set is used to obtain multiple text blocks that simultaneously contain the corresponding entities and are semantically similar, which are used as multiple first candidate results; if no entity is extracted, at least one second intermediate result set is directly used as the first candidate result. The process of obtaining the first intermediate result set includes: when N entities are extracted, querying the document identifier set corresponding to each entity in the entity relationship mapping index and calculating the intersection of each document identifier; retaining only the documents and text block location information that simultaneously contain all extracted entities as the first intermediate result set, where N is a positive integer greater than 1; if the number of documents simultaneously containing all extracted entities is zero, then starting from K=N-1, decreasing by 1 step to K=1, sequentially querying the documents and text block location information that contain at least K extracted entities until a non-empty query result is obtained, and determining the queried document and text block location information as the first intermediate result set; The method further includes, after receiving the current query information input by the user: Named entity recognition is performed on the current query information to obtain entities belonging to a preset entity type in the current query information; if the number of identified entities is greater than or equal to two, the query type of the current query information is determined to be a multi-entity relation condition query; if the number of identified entities is less than two, the query type of the current query information is determined to be an unstructured semantic condition query.

2. The method as described in claim 1, characterized in that, The full text content of each document is divided into blocks according to text fragments, including: Using the text fragment as the smallest indivisible unit, a sliding window method is used to combine several consecutive text fragments into a text block, wherein each text block contains a preset number of text fragments, and adjacent text blocks share a preset number of overlapping text fragments; and the document identifier corresponding to each generated text block is recorded.

3. The method as described in claim 2, characterized in that, Adjacent text blocks share a preset number of overlapping text segments, including: The number of overlapping segments is dynamically determined based on the semantic importance score of the text segments in the document, wherein the semantic importance score is calculated based on the entity density or keyword weight in the text segments; For text segments with semantic importance scores higher than the first threshold, they are retained as overlapping segments in two adjacent text blocks; For text segments whose semantic importance score is below the second threshold, they are not considered overlapping segments, meaning they only appear in a single text block.

4. The method as described in claim 1, characterized in that, The method further includes: When the query type of the received query information is a multi-entity relationship condition query, named entity recognition is performed on the current query information to extract entities that belong to the preset entity type; From the extracted entities, determine the first entity and the second entity, which are two entities that are explicitly specified in the query or that semantically constitute a relation pair; The implicit or explicit relationship type between the first entity and the second entity is parsed from the current query information. The relationship type is obtained by matching a predefined relation vocabulary or by semantic role annotation. Using the first entity as the subject entity, the relationship type, and the second entity as the object entity to form a triplet query condition, a matching record is retrieved in the entity relationship mapping index; wherein, each record in the entity relationship mapping index contains at least the subject entity identifier, relationship type, object entity identifier, source document identifier, and location information; The source document identifier and location information are extracted from all the retrieved matching records and used as the second candidate result.

5. The method as described in claim 1, characterized in that, Each first candidate result includes the document identifier, location information, and matching entity or entity relationship of the retrieved text block; Based on the multiple first candidate results, search results are generated, including: Using the document identifier as the grouping key, all candidate results belonging to the same document are aggregated into the same document group; Within the same document group, sort the candidate results according to the order in which their position information appears in the original document; For each candidate result, a display entry is generated, which includes at least: the matching entity or entity relationship, the page number recorded in the location information, the text fragment contained in the text block, and a link to the original document; All documents are grouped and their internal display items are combined in a preset order to generate search results.

6. A cross-document retrieval device, characterized in that, The device includes: The acquisition unit is used to parse multiple documents to be retrieved, and to obtain the full text content of each document and the position information of each text segment in the full text content; The construction unit is used to divide the full text content of each document into blocks according to text fragments, and then construct a semantic vector index based on the semantic vector corresponding to each text block, the document identifier, and the location information; and to construct an entity relationship mapping index based on each entity in the full text content of each document, the corresponding location information, the relationship between entities and the corresponding document identifier. The retrieval unit is used to retrieve the current query information based on the semantic vector index and the entity relationship mapping index when the query type of the received current query information is a semantic condition query, and obtain multiple first candidate results. The generation unit is used to generate search results based on multiple first candidate results; The retrieval unit is specifically used to: perform named entity recognition on the current query information, and determine whether an entity belonging to a preset entity type is extracted from the current query information; if at least one entity is extracted, the following two retrieval paths are executed respectively: Path 1: Utilize the entity relationship mapping index to query all documents and text block location information containing the extracted entity to obtain the first intermediate result set; Path 2: Convert the current query information into a semantic vector, and retrieve at least one text block in the semantic vector index whose similarity to the semantic vector exceeds a preset threshold, as at least one second intermediate result set. The intersection of the first intermediate result set and the second intermediate result set is used to obtain multiple text blocks that simultaneously contain the corresponding entities and are semantically similar, which are used as multiple first candidate results; if no entities are extracted, at least one second intermediate result set is directly used as the first candidate result; wherein, obtaining the first intermediate result set includes: when N entities are extracted, querying the document identifier set corresponding to each entity in the entity relationship mapping index and calculating the intersection of each document identifier; retaining only the document and text block location information that simultaneously contain all extracted entities as the first intermediate result set, where N is a positive integer greater than 1; if the number of documents that simultaneously contain all extracted entities is zero, starting from K=N-1, decreasing by 1 step to K=1, sequentially querying the document and text block location information that contain at least K extracted entities until a non-empty query result is obtained, and determining the queried document and text block location information as the first intermediate result set; The retrieval unit is further configured to, after receiving the current query information input by the user, perform named entity recognition on the current query information to obtain entities belonging to a preset entity type in the current query information; if the number of identified entities is greater than or equal to two, then the query type of the current query information is determined to be a multi-entity relation condition query; if the number of identified entities is less than two, then the query type of the current query information is determined to be an unstructured semantic condition query.

7. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-5.

Images