Multi-source document management method and device based on knowledge construction and fusion storage

Abstract

The invention discloses a multi-source document management method and device based on knowledge construction and fusion storage, and relates to the technical field of document management, and the method comprises the steps: receiving a multi-source document to an object storage system, and recognizing the document type; performing document analysis and structure extraction according to the document type; extracting pictures in the image-text mixed content, uploading the pictures to an object storage system, generating a mapping dictionary, and inserting picture marks in a text part of the mapping dictionary; carrying out structured processing on contents of the table key value pairs to extract summaries and abstracts; performing standardization processing and semantic slicing on the processed image-text mixed content, table key value pair content and / or plain text content to generate knowledge fragments; constructing a knowledge extracting questions from knowledge fragments; the knowledge fragments are stored in a first index, and the questions and IDs of the corresponding knowledge fragments are stored in a second index; generating vectors for each knowledge fragment and question, embedding and writing the vectors into a vector database; and performing document management based on the knowledge base. The document management efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of document management technology, and in particular to a multi-source document management method, apparatus, device, and medium based on knowledge construction and fusion storage. Background Technology

[0002] Intelligent question-answering technology based on Retrieval-Augmented Generation (RAG) has been applied in the field of document management. The performance of such systems is highly dependent on the quality of the underlying knowledge construction and storage efficiency.

[0003] In related technologies, the common processing paradigm is "document parsing → information extraction → embedding representation → knowledge storage," but it has the following limitations in processing multi-source heterogeneous documents: 1. Regarding document parsing, most existing document parsing tools can only extract plain text content from .docx, .pdf, and .xlsx formats, ignoring key information such as heading levels, table structures, and image descriptions, resulting in a lack of semantic context. Furthermore, multiple document formats require different tools for parsing, lacking a unified abstraction layer and an extensible loading mechanism, leading to high system integration complexity and poor versatility. Mainstream parsing tools also have weak support for domestic electronic document standards such as .ofd, hindering the implementation of these standards in government and enterprise scenarios.

[0004] 2. Regarding information extraction, most existing solutions rely solely on chunking and keyword strategies, failing to identify deeper semantic content such as key issues, conclusions, definitions, and logical reasoning relationships within documents. They also exhibit weak modeling capabilities for tables and charts, often failing to correctly reconstruct structured knowledge from complex tables, nested cells, and non-standard table headers, thus limiting information expressiveness.

[0005] 3. Regarding embedding representation, most existing solutions embed limited content and lack comprehensive semantic expression. Most systems only vectorize the main text, ignoring question-and-answer pairs, titles, figure captions, and other information within the document, failing to fully cover potential user query intents. Furthermore, embedding consumes significant computational resources, lacks incremental mechanisms, and struggles to adapt to dynamic knowledge update requirements.

[0006] 4. Regarding knowledge storage, existing knowledge storage solutions suffer from fragmented storage structures and a lack of a unified knowledge management layer. Multiple engines, such as vector libraries, full-text indexes, and original text storage, are deployed in a dispersed manner, with data consistency relying on external maintenance, resulting in poor system stability and scalability. Furthermore, there is a lack of cross-channel joint retrieval capabilities between vector and full-text indexes, preventing user queries from simultaneously combining semantic matching and keyword hits, thus limiting retrieval accuracy and response quality.

[0007] The aforementioned limitations result in the document management system not being able to fully extract and integrate the semantic information of multimodal documents, thus limiting management efficiency. Summary of the Invention

[0008] This invention provides a multi-source document management method, apparatus, device, and medium based on knowledge construction and fusion storage, which solves the problem that the semantic information of multimodal documents is not fully extracted and fused in the document management system, resulting in limited management efficiency.

[0009] To achieve the above objectives, this application adopts the following technical solution: Firstly, a multi-source document management method based on knowledge construction and integrated storage is provided, including: Receive uploaded multi-source documents to the object storage system and identify the document types; Based on the document type, the document is routed to the corresponding parsing engine for document parsing and structure extraction to obtain mixed text and image content, table key-value pair content, and / or plain text content. For the mixed text and image content, the images are extracted and uploaded to the object storage system to generate a {tag: storage address} mapping dictionary, and image tags are inserted into the text portion; for the table key-value pair content, structured processing is performed to extract summaries and abstracts; the processed mixed text and image content, table key-value pair content, and / or the plain text content are standardized. Knowledge fragments are generated from the text semantic slices obtained by the standardization process. Construct a knowledge base: Extract questions from the knowledge fragments based on a large language model; store the knowledge fragments in the first index, and store the questions and their corresponding knowledge fragment IDs in the second index to generate question-fragment pairs; generate vector embeddings for each knowledge fragment and question, write the vectors into the vector database, and establish a unique constraint: each vector is associated with only one question or knowledge fragment ID; Document management is based on the knowledge base.

[0010] Secondly, a multi-source document management device based on knowledge construction and fusion storage is provided, including: The document acquisition and recognition module is used to receive uploaded multi-source documents to the object storage system and identify the document type. The document parsing module is used to route the document to the corresponding parsing engine based on the document type for document parsing and structure extraction, to obtain mixed text and image content, table key-value pair content and / or plain text content; The content fusion module is used to extract images from the mixed text and image content, upload them to the object storage system, generate a {tag: storage address} mapping dictionary, and insert image tags into the text portion; to perform structured processing on the table key-value pair content to extract summaries and abstracts; and to standardize the processed mixed text and image content, table key-value pair content, and / or the plain text content. The semantic slicing module is used to generate knowledge fragments from the text semantic slices obtained by the standardization process; The knowledge base construction module is used to build a knowledge base: extracting questions from the knowledge fragments based on a large language model; storing the knowledge fragments in a first index, storing the questions and the IDs of the corresponding knowledge fragments in a second index, generating question-fragment pairs; generating vector embeddings for each knowledge fragment and question, writing the vectors into a vector database, and establishing a unique constraint: each vector is associated with only one question or knowledge fragment ID; The management operation module is used for document management based on the knowledge base.

[0011] Thirdly, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when executed by the processor, the computer program implements the steps of the multi-source document management method based on knowledge construction and fusion storage as described in the first aspect.

[0012] Fourthly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the multi-source document management method based on knowledge construction and fusion storage as described in the first aspect.

[0013] The multi-source document management method based on knowledge construction and fusion storage of the present invention has the following advantages: This application improves the multi-source document knowledge construction and storage system, with a more complete storage structure, supporting multimodal information fusion; stronger semantic representation capabilities of the knowledge base, richer retrieval paths, and optimized accuracy; strong document type adaptability, reducing document information loss; and the ability to support multi-source document parsing, structured extraction and question generation, realize multi-channel fusion embedding, and be compatible with heterogeneous storage backends. This enhances the intelligence, accuracy, coverage, and maintainability of the intelligent question-answering system, thereby improving document management efficiency.

[0014] The apparatus, electronic device, and readable storage medium corresponding to the multi-source document management method based on knowledge construction and fusion storage of this invention can achieve the same technical effect, and will not be described in detail here to avoid duplication. Attached Figure Description

[0015] Figure 1 A schematic flowchart illustrating a multi-source document management method based on knowledge construction and fusion storage, provided for an embodiment of this application; Figure 2 A schematic flowchart illustrating another multi-source document management method based on knowledge construction and fusion storage provided in an embodiment of this application; Figure 3 A schematic diagram of a system storage structure ER provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of a multi-source document management device based on knowledge construction and fusion storage provided in this application embodiment; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the technical solutions in the embodiments of this application are clearly described. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art are within the scope of protection of this application.

[0017] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0018] The steps described in the specification and the flowcharts in the accompanying drawings of this invention are not necessarily strictly executed according to the step numbers; the execution order of the method steps can be changed. Furthermore, certain steps can be omitted, multiple steps can be combined into one step, and / or one step can be broken down into multiple steps.

[0019] The following detailed description, in conjunction with the accompanying drawings and preferred embodiments, describes the multi-source document management method, apparatus, device, and medium based on knowledge construction and fusion storage provided in this application.

[0020] In the knowledge construction and storage scheme's processing paradigm of "document parsing → information extraction → embedded representation → knowledge storage": 1. Document Parsing: The document parsing module is the starting point of the knowledge construction process, responsible for converting raw documents in various formats into processable intermediate structures (such as text, images, tables, etc.). The document parsing module parses and extracts content from common office document formats (such as .docx, .pdf, .xlsx, etc.), using methods such as direct reading and character encoding recognition, using dedicated parsing libraries (such as Office) to read document structure, and using layout recognition models for layout analysis.

[0021] 2. Information Extraction: The information extraction module is used to extract semantically significant information units from the parsed original text, improving the structure and retrieval of knowledge representation. Information extraction typically includes text segmentation, question-answer pair extraction, summary extraction, table and text parsing, etc.

[0022] 3. Embedding Representation: The embedding representation module is used to convert text or structured information into vector representations, enabling downstream semantic retrieval. A common approach is to use pre-trained vector models to convert text or structured information into semantic vectors. For content containing images, multimodal models can be used to extract image semantic vectors.

[0023] 4. Knowledge Storage: The knowledge storage module is responsible for writing the constructed knowledge fragments and their vectorized representations into the target storage system for downstream retrieval. The storage system typically includes a vector database supporting similarity retrieval; a text indexing engine supporting keyword queries and metadata filtering, etc.

[0024] In practical knowledge management applications in enterprises, such as finance (reports / prospectuses), manufacturing (equipment drawings), government affairs (official document circulation), healthcare (scientific research literature), and customer service (product manuals), the limitations described in the background technology restrict the application of RAG systems to larger-scale and more complex knowledge forms, and also prevent them from fully leveraging the knowledge value contained in multi-source and multimodal enterprise documents.

[0025] To improve document management efficiency, this application provides an improved method for constructing and storing multi-source document knowledge, applicable to enterprise-level scenarios requiring structured knowledge extraction and question-answering enhancement for multi-format documents. Starting from document upload, this application sequentially completes format parsing, content slicing, structural information extraction, vectorized embedding, and fusion storage, forming a complete knowledge support system for Retrieval Enhanced Generation (RAG). It supports multi-source document parsing, structured extraction and question generation, achieves multi-channel fusion embedding, and is compatible with heterogeneous storage backends, thereby improving the intelligence, accuracy, coverage, and maintainability of enterprise-level intelligent question-answering systems, and ultimately enhancing document management efficiency.

[0026] Please see Figure 1-2 This application provides a multi-source document management method based on knowledge construction and fusion storage, such as... Figure 1-2 As shown, it includes: Step S1: Receive uploaded multi-source documents to the object storage system; and identify the document types.

[0027] Users upload documents to the MinIO object storage system, which records the path and original content. After uploading, an automatic recognition process is triggered, and the system determines the document type based on the file extension, such as .docx, .pdf, .ofd, .xlsx, .txt, etc.

[0028] Step S2: Based on the document type, the document is routed to the corresponding parsing engine for document parsing and structure extraction to obtain mixed text and image content, table key-value pair content, and / or plain text content.

[0029] The system determines the document type based on the file extension. Based on the determination result, the system routes the file to different format parsing modules for further processing. This step S2 specifically includes: Step S21: Extract titles, paragraphs, tables, and images from the .docx document; Step S22: Extract the structured text and embed resources from the .pdf document; Step S23: Convert the .ofd document to .pdf format and extract the text and embedded resources in a structured manner; Step S24: Identify the title, header, and row data of the .xlsx or .csv document and concatenate them into key-value pairs; Step S25: Divide the .txt document into paragraph texts.

[0030] In practice: .docx documents are parsed using a DOCX parsing engine to extract titles, paragraphs, tables, and images; .pdf documents are parsed using a PDF engine to extract structured text and embedded resources; .ofd documents are converted using an OFD to PDF module and then processed using a PDF engine; .xlsx or .csv table-type documents are parsed using a table parsing engine to identify titles and headers, and this information is then concatenated with each row of the table to form key-value pairs; .txt text files are processed into paragraph text using a plain text extractor. The processing results mainly exist in two forms: the first is mixed text and image content, including structured paragraphs and images; the second is structured table content or plain text content.

[0031] Step S3: For the mixed text and image content, extract the images and upload them to the object storage system to generate a {tag: storage address} mapping dictionary, and insert image tags into its text portion; for the table key-value pair content, perform structured processing to extract summaries and abstracts; and perform standardization processing on the processed mixed text and image content, table key-value pair content, and / or the plain text content.

[0032] In practice, for document paragraphs containing images, the system uploads the images to MinIO and generates a mapping dictionary between image tags and image addresses, for example: {"img_001": "minio: / / xx / xx.png"} Insert image tags (such as [img_001]) into the corresponding positions in the original text to bind the images and text, thus achieving image-text fusion.

[0033] The table key-value pairs are structured, summarized, and extracted.

[0034] The processed mixed text and image content, table key-value pair content, and plain text content are sent to the cleaning module to unify and standardize the text structure.

[0035] Step S4: Generate knowledge fragments from the text semantic slices obtained by the standardization process.

[0036] In practice, the cleaned and standardized text is sent to the semantic slicing module, divided into logical and semantic paragraphs, and knowledge fragment text is generated for storage.

[0037] Step S5, construct the knowledge base: extract questions from the knowledge fragments based on the large language model; store the knowledge fragments in the first index, and store the questions and their corresponding knowledge fragment IDs in the second index to generate question-fragment pairs; generate vector embeddings for each knowledge fragment and question, write the vectors into the vector database, and establish unique constraints: Each vector is associated with only the ID of a question or knowledge fragment.

[0038] In practice, a large language model is used to extract questions from knowledge fragments (semantic slices) of text, generating corresponding question texts. For example, inputting a knowledge fragment into the large language model outputs at least one semantically relevant question text: "What is the core process of this description?". The original slices (containing image mapping information) are stored in Elasticsearch (ES1 index); the extracted questions and their corresponding original slice IDs are written together into another Elasticsearch index, ES2, forming question-slice pairs and establishing a strong association between the question and the slice ID. The system uses an embedding model to generate vector representations based on the slice and question content, and writes them uniformly into the Milvus vector database; each vector record is associated with only one chunk_id or question_id, and a unique constraint is set to ensure that the old data is overwritten after the embedding is updated, maintaining index consistency.

[0039] Furthermore, the storage structure of the knowledge base includes: The knowledge fragment entity is stored in the first index, and its fields include: _id, the primary key, which uniquely identifies the knowledge fragment; chunk_text, the content of the knowledge fragment; source, a foreign key, which points to the original document from which the knowledge fragment originates; and images, a dictionary of image and text tag mappings. The question fragment entity is stored in the second index, and its fields include: _id, the primary key, which uniquely identifies the question; question_text, the question content; and es1_chunk_id, a foreign key that points to the primary key of the associated knowledge fragment entity. Vector-embedded entities are stored in a vector database. Their fields include: id (primary key, unique identifier vector); embedding (semantic vector represented by a floating-point array); es1_chunk_id (nullable foreign key, pointing to the primary key of the knowledge fragment entity); es2_chunk_id (nullable foreign key, pointing to the primary key of the question entity); and a constraint rule that each vector record can only be associated with either es1_chunk_id or es2_chunk_id, and only one valid vector record is retained for the same entity primary key. The original document storage entity is stored in an object storage system. Its fields include: file_path, the primary key, which is the document storage path; and content, which is the binary content of the original document.

[0040] Specifically, the overall ER relationship of the system storage structure is as follows: Figure 3 As shown. The entire storage structure consists of the following four types of entities: 1. ES1: Knowledge Fragment (Text Slice) Entity. ES1 is the most basic knowledge unit in the system, representing text paragraph information after semantic slicing. This entity's fields include: 1) _id (primary key): uniquely identifies each slice; 2) chunk_text: The content of the text slice; 3) source (foreign key): points to MinIO.file_path, representing the original document from which this slice originates; 4) images: Image and text tag mapping dictionary, which records the mapping relationship between image tags in the slice and storage addresses.

[0041] This entity is associated with multiple modules and serves as a connecting hub for operations such as vectorization, question generation, and document tracing.

[0042] 2. ES2: Question Entity. ES2 represents a semantic question extracted from a text slice (ES1) to enhance question-answering capabilities. Fields include: 1) _id (primary key): uniquely identifies each issue; 2) question_text: The text content of the question; 3) es1_chunk_id (foreign key): points to the text slice ID (i.e. ES1._id) that this problem depends on.

[0043] Each text slice can generate multiple questions, forming a one-to-many relationship between ES1 and ES2. Question embedding and retrieval can serve as additional semantic paths.

[0044] 3. Milvus: Vector Embedding Entity. The Milvus entity stores semantic vector information, supporting efficient retrieval based on vector similarity. Its field structure is as follows: 1) id (primary key): A unique identifier for an embedded vector entry; 2) embedding: a float array representing semantic vector values; 3) es1_chunk_id (foreign key, can be null): points to the ID of the source slice; 4) es2_chunk_id (foreign key, can be null): points to the ID of the source problem.

[0045] Embedded data conventions: Each vector record can only be associated with one slice or question, and double associations are not allowed; each entity retains only one valid embedded record (unique index). This ensures that the vector representation of any knowledge unit in the system is unique and updatable, thereby guaranteeing index quality and semantic consistency.

[0046] ES1 and Milvus, as well as ES2 and Milvus, have a one-to-one relationship. Each slice / problem stores only one vector record in the embedding library.

[0047] 4. MinIO: Original document storage entity. The MinIO entity is used to store the original uploaded document and its content. Fields include: 1) file_path (primary key): A unique path identifier for a document; 2) content: The original content of the document (binary storage); Each text slice traces back to the original file via the ES1.source field, enabling a traceable association between knowledge and documents, supporting subsequent operations such as referencing, locating, and displaying. ES1 and MinIO form a many-to-one relationship, where multiple slices can correspond to the same original document.

[0048] Once the final construction process is complete, the entire knowledge base includes: Structured content (ES) that can be used for full-text search and citation location; semantic representation (Milvus) that can be used for semantic matching and vector retrieval; and original text storage (MinIO) that can be used to trace original files and resources.

[0049] Step S6: Perform document management based on the knowledge base. Document management operations are performed based on the knowledge base.

[0050] Based on the above-mentioned plan, this application has the following advantages: 1. More complete storage structure, supporting multimodal information fusion This solution preserves the original document content, along with its structure, images, tables, and other information. By storing the sliced ​​text and image mappings using ES1, MinIO retains the original document content, constructing a hierarchical processing layer from the original document → slices → question / slice pairs → vector embeddings, thus achieving unified management and referencing of multimodal information.

[0051] 2. The knowledge base has stronger semantic representation capabilities, richer retrieval paths, and optimized accuracy. This solution automatically generates multiple questions (ES2) based on sliced ​​text and embeds vectors independently for each question, constructing a "multiple questions, one answer" semantic graph to improve question diversity and matching error tolerance. It also maintains structured information (ES1, ES2) and semantic vector information (Milvus), supporting vector / keyword fusion retrieval schemes to adapt to different business scenario requirements.

[0052] 3. Strong document type adaptability, reducing document information loss. This solution effectively supports mainstream enterprise document formats including .docx, .pdf, .ofd, .xlsx, .csv, and .txt, and supports customized processing such as paragraph extraction, structure reconstruction, field recognition, and table decomposition, ensuring semantic integrity and structural fidelity.

[0053] See Figure 4 Corresponding to the above embodiments of the multi-source document management method based on knowledge construction and fusion storage, this application provides a multi-source document management device based on knowledge construction and fusion storage, including: The document acquisition and recognition module 1001 is used to receive multi-source documents uploaded to the object storage system and to identify the document type. The document parsing module 1002 is used to route to the corresponding parsing engine according to the document type for document parsing and structure extraction, to obtain mixed text and image content, table key-value pair content and / or plain text content; The content fusion module 1003 is used to extract images from the mixed text and image content, upload them to the object storage system, generate a {tag: storage address} mapping dictionary, and insert image tags into the text portion; perform structured processing on the table key-value pair content to extract summaries and abstracts; and perform standardization processing on the processed mixed text and image content, table key-value pair content, and / or the plain text content. Semantic slicing module 1004 is used to generate knowledge fragments from the text semantic slices obtained by the standardization process; The knowledge base construction module 1005 is used to construct a knowledge base: extracting questions from the knowledge fragments based on a large language model; storing the knowledge fragments in a first index, storing the questions and the IDs of the corresponding knowledge fragments in a second index, generating question-fragment pairs; generating vector embeddings for each knowledge fragment and question, writing the vectors into a vector database, and establishing a unique constraint: each vector is associated with only one question or knowledge fragment ID; The management operation module 1006 is used for document management based on the knowledge base.

[0054] Furthermore, the document parsing module 1002 is specifically used for: Extract titles, paragraphs, tables, and images from a .docx document; Extract structured text and embed resources from .pdf documents; Convert .ofd documents to .pdf format and extract structured text and embedded resources; Identify the title, header, and row data in .xlsx or .csv documents and concatenate them into key-value pairs; Split a .txt document into paragraph text.

[0055] Furthermore, the storage structure of the knowledge base includes: The knowledge fragment entity is stored in the first index, and its fields include: _id, the primary key, which uniquely identifies the knowledge fragment; chunk_text, the content of the knowledge fragment; source, a foreign key, which points to the original document from which the knowledge fragment originates; and images, a dictionary of image and text tag mappings. The question fragment entity is stored in the second index, and its fields include: _id, the primary key, which uniquely identifies the question; question_text, the question content; and es1_chunk_id, a foreign key that points to the primary key of the associated knowledge fragment entity. Vector-embedded entities are stored in a vector database. Their fields include: id, the primary key and unique identifier vector; embedding, a semantic vector represented by a floating-point array; es1_chunk_id, a nullable foreign key pointing to the primary key of the knowledge fragment entity; es2_chunk_id, a nullable foreign key pointing to the primary key of the question entity; and constraint rules. The original document storage entity is stored in an object storage system. Its fields include: file_path, the primary key, which is the document storage path; and content, which is the binary content of the original document.

[0056] Furthermore, the constraint rule is as follows: Each vector record can only be associated with either es1_chunk_id or es2_chunk_id, and only one valid vector record is retained for the same entity primary key.

[0057] The aforementioned multi-source document management device based on knowledge construction and fusion storage implements the steps and processes of the aforementioned multi-source document management method based on knowledge construction and fusion storage, and achieves the same technical effect. To avoid repetition, these will not be repeated here.

[0058] See Figure 5 Corresponding to the above embodiments of the multi-source document management method based on knowledge construction and fusion storage, this application provides an electronic device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps and processes of the above embodiments of the multi-source document management method based on knowledge construction and fusion storage, and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0059] The memory 1009 can be used to store software programs and various data. The memory 1009 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback function, image playback function, etc.). Furthermore, the memory 1009 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 1009 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0060] The processor 1010 may include one or more processing units; optionally, the processor 1010 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor 1010.

[0061] Corresponding to the above embodiments of the multi-source document management method based on knowledge construction and fusion storage, this application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the steps and processes of the above embodiments of the multi-source document management method based on knowledge construction and fusion storage, and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0062] The processor is the processor in the electronic device described in the above embodiments of this application. The readable storage medium includes a computer-readable storage medium, such as a computer read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk.

[0063] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0064] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0065] It is understood that the embodiments of this application have been described above in conjunction with the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. As those skilled in the art will know, various changes or equivalent substitutions can be made to these features and embodiments without departing from the spirit and scope of the invention. Furthermore, those skilled in the art, under the guidance or instruction of this application, can modify these features and embodiments to adapt to specific situations and materials without departing from the spirit and scope of the invention. Therefore, this invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are within the protection scope of this invention.

Claims

1. A multi-source document management method based on knowledge construction and integrated storage, characterized in that, include: Receive uploaded multi-source documents to the object storage system; And identify document types; Based on the document type, the document is routed to the corresponding parsing engine for document parsing and structure extraction to obtain mixed text and image content, table key-value pair content, and / or plain text content. For the mixed text and image content, the images are extracted and uploaded to the object storage system to generate a {tag: storage address} mapping dictionary, and image tags are inserted into the text portion; for the table key-value pair content, structured processing is performed to extract summaries and abstracts; the processed mixed text and image content, table key-value pair content, and / or the plain text content are standardized. Knowledge fragments are generated from the text semantic slices obtained by the standardization process. Building a knowledge base: Extracting questions from the knowledge fragments based on a large language model; Store knowledge fragments in the first index and store the questions and their corresponding knowledge fragment IDs in the second index to generate question-fragment pairs; generate vector embeddings for each knowledge fragment and question, write the vectors to the vector database, and establish a unique constraint: each vector is associated with only one question or knowledge fragment ID; Document management is based on the knowledge base.

2. The multi-source document management method based on knowledge construction and fusion storage according to claim 1, characterized in that, The process of routing documents to the corresponding parsing engine based on document type for document parsing and structure extraction to obtain mixed text and image content, table key-value pair content, and / or plain text content includes: Extract titles, paragraphs, tables, and images from a .docx document; Extract structured text and embed resources from .pdf documents; Convert .ofd documents to .pdf format and extract structured text and embedded resources; Identify the title, header, and row data in .xlsx or .csv documents and concatenate them into key-value pairs; Split a .txt document into paragraph text.

3. The multi-source document management method based on knowledge construction and fusion storage according to claim 1, characterized in that, The storage structure of the knowledge base includes: The knowledge fragment entity is stored in the first index, and its fields include: _id, the primary key, which uniquely identifies the knowledge fragment; chunk_text, the content of the knowledge fragment; source, a foreign key, which points to the original document from which the knowledge fragment originates; and images, a dictionary of image and text tag mappings. The question fragment entity is stored in the second index, and its fields include: _id, the primary key, which uniquely identifies the question; question_text, the question content; and es1_chunk_id, a foreign key that points to the primary key of the associated knowledge fragment entity. Vector-embedded entities are stored in a vector database. Their fields include: id, the primary key and unique identifier vector; embedding, a semantic vector represented by a floating-point array; es1_chunk_id, a nullable foreign key pointing to the primary key of the knowledge fragment entity; es2_chunk_id, a nullable foreign key pointing to the primary key of the question entity; and constraint rules. The original document storage entity is stored in an object storage system. Its fields include: file_path, the primary key, which is the document storage path; and content, which is the binary content of the original document.

4. The multi-source document management method based on knowledge construction and fusion storage according to claim 3, characterized in that, The constraint rules are as follows: Each vector record can only be associated with either es1_chunk_id or es2_chunk_id, and only one valid vector record is retained for the same entity primary key.

5. A multi-source document management device based on knowledge construction and fusion storage, characterized in that, include: The document acquisition and recognition module is used to receive uploaded multi-source documents to the object storage system; And identify document types; The document parsing module is used to route the document to the corresponding parsing engine based on the document type for document parsing and structure extraction, to obtain mixed text and image content, table key-value pair content and / or plain text content; The content fusion module is used to extract images from the mixed text and image content, upload them to the object storage system, generate a {tag: storage address} mapping dictionary, and insert image tags into the text portion; to perform structured processing on the table key-value pair content to extract summaries and abstracts; and to standardize the processed mixed text and image content, table key-value pair content, and / or the plain text content. The semantic slicing module is used to generate knowledge fragments from the text semantic slices obtained by the standardization process; The knowledge base construction module is used to build a knowledge base: extracting questions from the knowledge fragments based on a large language model; Store knowledge fragments in the first index and store the questions and their corresponding knowledge fragment IDs in the second index to generate question-fragment pairs; generate vector embeddings for each knowledge fragment and question, write the vectors to the vector database, and establish a unique constraint: each vector is associated with only one question or knowledge fragment ID; The management operation module is used for document management based on the knowledge base.

6. The multi-source document management device based on knowledge construction and fusion storage according to claim 5, characterized in that, The document parsing module is specifically used for: Extract titles, paragraphs, tables, and images from a .docx document; Extract structured text and embed resources from .pdf documents; Convert .ofd documents to .pdf format and extract structured text and embedded resources; Identify the title, header, and row data in .xlsx or .csv documents and concatenate them into key-value pairs; Split a .txt document into paragraph text.

7. The multi-source document management device based on knowledge construction and fusion storage according to claim 5, characterized in that, The storage structure of the knowledge base includes: The knowledge fragment entity is stored in the first index, and its fields include: _id, the primary key, which uniquely identifies the knowledge fragment; chunk_text, the content of the knowledge fragment; source, a foreign key, which points to the original document from which the knowledge fragment originates; and images, a dictionary of image and text tag mappings. The question fragment entity is stored in the second index, and its fields include: _id, the primary key, which uniquely identifies the question; question_text, the question content; and es1_chunk_id, a foreign key that points to the primary key of the associated knowledge fragment entity. Vector-embedded entities are stored in a vector database. Their fields include: id, the primary key and unique identifier vector; embedding, a semantic vector represented by a floating-point array; es1_chunk_id, a nullable foreign key pointing to the primary key of the knowledge fragment entity; es2_chunk_id, a nullable foreign key pointing to the primary key of the question entity; and constraint rules. The original document storage entity is stored in an object storage system. Its fields include: file_path, the primary key, which is the document storage path; and content, which is the binary content of the original document.

8. The multi-source document management device based on knowledge construction and fusion storage according to claim 7, characterized in that, The constraint rules are as follows: Each vector record can only be associated with either es1_chunk_id or es2_chunk_id, and only one valid vector record is retained for the same entity primary key.

9. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the multi-source document management method based on knowledge construction and fusion storage as described in any one of claims 1 to 4.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the multi-source document management method based on knowledge construction and fusion storage as described in any one of claims 1 to 4.

Images