A virtual file system interaction method and system based on vector retrieval

Abstract

This invention relates to the field of semantic retrieval technology, and more particularly to a virtual file system interaction method and system based on vector retrieval. The method includes: establishing a semantic index for the files in the virtual file system and storing it in a vector database; receiving a user's semantic query request and encoding it into a query vector, performing a similarity retrieval in the vector database to obtain a set of matching files; dynamically constructing a virtual result directory based on this set, generating a virtual file item for each matching file, and establishing a mapping relationship between the virtual file item and the location information of the real file; presenting the virtual result directory as a local directory accessible to the operating system through a user-mode virtual file system; intercepting user file operation requests for virtual file items and routing them to the corresponding real files according to the mapping relationship. This invention enables semantic retrieval results to be directly manipulated in the form of a local file system directory, realizing an integrated interaction from semantic query to file access.

Description

Technical Field

[0001] This invention relates to the field of semantic retrieval technology, and in particular to a virtual file system interaction method and system based on vector retrieval. Background Technology

[0002] As enterprises become increasingly digital, the number and variety of files faced by individuals and organizations are growing dramatically. Traditional file systems only support exact matching searches based on filenames and paths, and cannot understand the semantics of file content. In recent years, the industry has seen the emergence of technical solutions that mount heterogeneous storage devices such as object storage, block storage, tape libraries, and optical disc libraries as local directories through user-space virtual file systems. These virtual file systems achieve unified accessibility for online, near-line, and offline files through protocol conversion, unified namespaces, and metadata persistence. Users can manipulate files on remote or archive media as if they were local files through POSIX standard interfaces.

[0003] However, while the aforementioned virtual file systems solve the problem of unified access to heterogeneous storage, users still need to know the approximate path or filename of the file to locate and access the target file. When users do not know the directory where the file is located, do not remember the filename, or only remember the semantic features of the file content, the above systems cannot provide effective means of file discovery and access.

[0004] Existing semantic retrieval solutions typically deploy the retrieval system as an independent external service to the file system, which presents the following problems: (1) Separation of search results from file system operations. Existing semantic search systems typically only return a list of file paths or present search results in the form of web pages. After obtaining the search results, users still need to switch to a file manager to find and open files one by one according to the path. They cannot directly open, copy, or perform batch operations on the search results interface. Search results cannot be viewed and managed as a whole like ordinary folders.

[0005] (2) The search results cannot be continuously refined. In the existing semantic search, each query is independent of the others. After a user obtains a batch of results from the first search, if further filtering is needed within the results, a new round of search must be launched across the entire database. It is not possible to converge the range based on the existing result set. Each refinement query requires reconstructing the query conditions and traversing the entire database. The search efficiency decreases significantly as the file size increases.

[0006] (3) Multi-modal file retrieval capability is insufficient. For picture files, the traditional image search image scheme uses a visual feature vector for image similarity matching. The feature vector of a multi-theme picture is diluted by multiple subject signals, and the retrieval accuracy decreases. At the same time, the description words of the uploaded picture during retrieval are inconsistent with the index description words of the searched picture, which can easily lead to matching failure. For scanned PDF files, the traditional text extraction method returns empty content because there is no embedded text layer, which leads to the fact that such files cannot be indexed and retrieved at all.

[0007] (4) There is a window period of inconsistency between the index and the file system state. The existing semantic retrieval scheme maintains the vector index as an independent component from the file system. Index updating and file operation are performed in different threads or different services, and there is a window period in which the file has been deleted but the index still exists, or the file has been created but the index has not been established.

[0008] (5) The process of uploading and establishing an index lacks real-time progress feedback. The traditional asynchronous uploading index task only returns the final processing result, and the calling party cannot obtain intermediate state information such as the number of files completed, the specific files and reasons for processing failure, and the details of the skipped files during the processing process. SUMMARY

[0009] Therefore, the present application provides a virtual file system interaction method and system based on vector retrieval to overcome the problems of the prior art that the semantic retrieval result and the file system operation are separated from each other, the retrieval result cannot be directly operated in the form of a directory, the multi-modal file retrieval capability is insufficient, and the index state is inconsistent.

[0010] To achieve the above-mentioned purpose, the present application provides a virtual file system interaction method based on vector retrieval. It comprises: Step S1, on the basis of the file metadata of the virtual file system, content semantic indexes of the files in the virtual file system are established and stored in a vector database. The content semantic indexes at least include file identification information for positioning the files, file original paths, and vector data obtained by encoding the file content by an encoding model; Step S2, receiving a semantic query request submitted by a user and encoding it into a query vector, performing similarity retrieval in the vector database with the query vector, and obtaining a matching file set composed of file identification information; Step S3, according to the matching file set, dynamically constructing a virtual result directory and generating a corresponding virtual file item for each matching file, the virtual file item at least including display information and similarity information, and establishing a mapping relationship between each virtual file item and its corresponding real file location positioning information; Step S4, presenting the virtual result directory as a local directory accessible to the operating system through the user-mode virtual file system. Step S5: Intercept the file operation request initiated by the user on the virtual file item in the local directory, obtain the location information of the corresponding real file according to the mapping relationship, and route the operation request to the corresponding real file.

[0011] Furthermore, the dynamically constructed virtual result directory includes: A virtual directory name is generated based on semantic query information, timestamp, and session identifier; For each matched file, a virtual file item is constructed. The virtual file item includes at least a display name, file identification information, file attribute information, similarity information, original path mapping information, and storage status information. The display name is either the filename of the real file or a semantic name generated based on the query content. The virtual file items are sorted in descending order of similarity information.

[0012] Furthermore, the interception of file operation requests initiated by the user on the virtual file item includes at least one of the following: The directory listing operation, if intercepted, queries the mapping relationship and returns a list of attribute information for all virtual file items in the current virtual result directory, without reading the actual file content; If the attribute query operation is intercepted, the attribute information of the corresponding real file is obtained and returned according to the mapping relationship. If the open operation is blocked, the real file is located according to the mapping relationship, and an operation handle is established after permission and availability verification. If a read operation is intercepted, the content is read from the storage location of the real file according to the mapping relationship and returned. If the copy operation is intercepted, the actual file content is retrieved through a read operation and then transferred to the target location.

[0013] Furthermore, the virtual results directory is set to read-only mode by default: Allow users to browse, open, and copy virtual file items, but prohibit write, delete, and rename operations; When it is necessary to modify the original file, guide the user to perform the modification operation through the directory where the original file is located; When the same real file appears in multiple virtual result directories, deleting a virtual file item in any virtual result directory only removes the current mapping relationship and does not delete the real file.

[0014] Furthermore, it also includes the ability to continue searching within the current virtual results directory and manage multiple directory mappings: The system maintains the search session state, creating a session identifier and storing a set of file identifier information corresponding to the current search results upon the first search. Receive a user's request to continue searching within the current virtual results directory, and use the set of file identifier information as a filter condition to ensure that the search is only performed within that set. After the search is completed, a sub-virtual result directory is generated or the current virtual result directory is updated, and the stored file identification information set is updated. Each round of search uses the file identification information set of the previous round of results as the filtering boundary, forming a hierarchical virtual result directory system. When the same real file appears in different virtual result directories due to responses to different semantic queries, the system creates an independent mapping record for each occurrence, and each mapping record points to the location information of the same real file.

[0015] Furthermore, it also includes an index synchronization and maintenance mechanism based on operation logs: When a file in the virtual file system is modified, the system generates a corresponding file event and writes it to the operation log; When a file is created, an index is built after the content is written to disk and the index status is marked as ready; When a file is modified, first delete all old index records of the file in the vector database, then re-extract the content, encode it, and write it into a new record. After completion, set the index status to ready and mark the relevant virtual file items as pending refresh. If re-indexing fails, retain the previous version of the index record. When deleting a file, first lock the file identification information to prevent concurrent indexing operations, and then clear the index records and all mapping relationships; The virtual results directory displays virtual file items with an indexed status of "ready," and displays the corresponding status identifier for virtual file items with an indexed status of "pending" or "failed."

[0016] Furthermore, the establishment of the content semantic index includes the extraction of differentiated content from different types of files: For text files, the text content is directly extracted and encoded. For image files, during indexing, the complexity of the image is determined by a visual language model, and the length of the description is adaptively allocated according to the number of subjects. In simple images with one or two subjects, the subject descriptions account for a higher proportion of the text, while in complex images with three or more subjects, the subject descriptions are evenly distributed. The background is uniformly represented by keyword tags, and the generated descriptive text is then encoded. During retrieval, if the semantic query request submitted by the user is for an image, the basic general category name is extracted from the query image through the visual language model, and then the subject name is expanded into the corresponding category word through the local category dictionary to construct a multi-word query containing the subject name and category word for semantic retrieval.

[0017] Furthermore, it also includes automatic identification of scanned documents and optical character recognition as a fallback: The embedded text layer is first extracted from the PDF file. If the amount of extracted text is lower than a preset threshold, the file is determined to be a scanned file. After rendering the pages of the scanned document into an image, optical character recognition is performed. After filtering out noisy lines from the recognition results, the concatenated text is indexed as the file content. The noisy line filtering includes filtering lines consisting of pure whitespace or separators, as well as lines with a length less than a preset value and containing no Chinese characters. When the total number of pages in the document exceeds the page limit, only the first preset number of pages will be processed, and a truncation prompt will be added to the end of the text.

[0018] Furthermore, it also includes incremental deduplication and real-time state tracking: When building a semantic index for content, the hash value of the path of the file to be indexed is used as a record identifier prefix. The existence of a record with this prefix in the vector database is used to determine whether the file has been indexed. If the file is already indexed, the file size and modification time stored in the record are compared with the current file. The file size is compared with an integer for precision, while the modification time is compared with a preset tolerance range of seconds because it is stored as a floating-point number and there is a loss of precision. When the file sizes are the same and the difference in modification time is within the tolerance range, the re-encoding process of the file is skipped. It accepts a mixed input list containing file paths and folder paths, and recursively expands the folder paths into a flat list of files; Before starting file-by-file processing, all files to be processed are written to the task details with a preset status. During the processing, the status and count of each file are updated in real time after each file is completed. The processing status values ​​include success, failure, skipped, and pending.

[0019] A system for applying the vector-based virtual file system interaction method includes: The semantic indexing module is used to store file identification information, original file path, and vector data obtained by encoding the file content through an encoding model as a unified content semantic index based on the file metadata of the virtual file system. The vector retrieval module is used to receive semantic query requests and encode them into query vectors, and perform similarity retrieval in the vector database based on the query vectors to obtain a set of matching files composed of file identification information; The virtual directory generation module is used to dynamically construct a virtual result directory based on the set of matched files, generate a virtual file item for each matched file, and establish a mapping relationship between each virtual file item and the location information of its corresponding real file. The virtual file system adaptation module is used to present the virtual result directory as a local directory accessible to the operating system through the user-mode virtual file system, and to intercept file operation requests initiated by the user on the virtual file items. The file operation routing module is used to route the intercepted file operation requests to the corresponding real files according to the mapping relationship and return the file content or attribute information.

[0020] Compared with existing technologies, the beneficial effects of this invention are as follows: This embodiment establishes a content semantic index based on the existing metadata of the virtual file system, and adopts differentiated content extraction strategies for different file types such as text, images, and portable documents, enabling high-quality semantic indexes to be established for multimodal files. Incremental deduplication and modification time tolerance comparison skip duplicate processing of unchanged files, improving index building efficiency. Real-time status tracking allows callers to view the processing status and progress of each file at any time. When a user submits a semantic query, the system encodes the query into a vector in the same semantic space as the index, and uses a hybrid retrieval strategy to obtain a set of matching files. Image queries construct multi-word queries through category extraction and dictionary expansion, solving the problems of inconsistent terminology in image and text retrieval and decreased accuracy in multi-subject image retrieval. The number of searches is set according to the cognitive load principle to ensure that the results are presented completely on a single page. Therefore, users do not need to know the file path or name; they can obtain a set of semantically matched files based solely on natural language or images, laying the foundation for the subsequent construction of an operable virtual directory and realizing an integrated interaction from semantic discovery to file access.

[0021] Furthermore, this embodiment generates semantically meaningful and unique virtual directory names based on query content, timestamps, and session identifiers, enabling users to intuitively identify different search sessions in the file manager. For each matching file, a virtual file item is constructed, containing a display name, file attributes, similarity score, storage status, and original path mapping. When the original file name is a meaningless number, a semantic name is automatically generated using query keywords, significantly improving the readability of search results and user identification efficiency. Each virtual file item is sorted in descending order of similarity, and when scores are the same, they are sorted again by modification time, ensuring that the most relevant and up-to-date files are presented first. Simultaneously, the system maintains a set of file identifiers for the current session, providing filtering boundaries for continued searching within the directory, allowing multiple rounds of searching to continuously converge within the existing results without repeatedly traversing the entire database. Throughout the process, virtual file items only store mapping relationships without copying real files; the same file can appear in multiple virtual directories without creating storage redundancy, achieving instant presentation and efficient management of search results.

[0022] Furthermore, this embodiment maintains session state and file identifier set, enabling users to continuously submit new search conditions within the current virtual result directory. Each round of search uses the file identifier set of the previous round's results as the filtering boundary, and the search scope converges round by round without repeatedly traversing the entire database. The search efficiency increases significantly with each round. At the same time, each round of search generates a sub-virtual directory and mounts it to the current directory, forming a hierarchical directory structure from coarse to fine. Users can trace the search path along the directory hierarchy and intuitively understand the result convergence process. In terms of multi-directory mapping, the system creates independent mapping records for each appearance of the same real file in different virtual result directories through a mapping table. All records point to the same unique file identifier, so that the file only needs to be stored once and can be repeatedly presented in multiple semantic query results without any storage redundancy. Moreover, the deletion operation in any virtual directory only removes the mapping record of the current view and does not affect the presentation in other directories or the real file itself. Thus, while realizing multi-view organization and zero-redundancy storage of search results, it ensures data security and operational semantic consistency in multi-view scenarios.

[0023] Furthermore, this embodiment achieves synchronous maintenance of file system operations and semantic indexes through the transaction mechanism of operation logs and state machines, effectively avoiding the window period of inconsistency between file changes and indexes. At the same time, through file locking mechanisms and old version retention strategies, the security of index operations and the continuity of retrieval services are guaranteed while ensuring consistency.

[0024] Furthermore, this embodiment first extracts the embedded text layer from portable documents, automatically determines the file type based on statistical thresholds, and directly uses the extracted text for normal files with zero additional overhead. Scanned files are converted into indexable text through rendering and recognition, achieving differentiated processing of mixed file sets. Rendering parameters are dynamically adjusted according to the page width, balancing recognition rate and processing efficiency. The recognition engine uses lazy loading and singleton reuse to avoid repeated initialization overhead. If loading fails, it is permanently marked so as not to retry, ensuring system stability. Noise line filtering effectively removes invalid noise through dual judgment of delimiter mode and character, improving the quality of indexed text. When the page limit is exceeded, only the beginning is processed and a truncation prompt is added for encoding, so that users know the index coverage range, thereby converting scanned files into searchable content and significantly expanding the file coverage of the semantic retrieval system.

[0025] Furthermore, this embodiment significantly skips the repetitive processing of unchanged files while ensuring index accuracy through incremental deduplication and real-time status tracking mechanisms, thereby significantly improving index building efficiency. At the same time, it allows the caller to know the processing status and progress of each file in real time during the processing without waiting for all tasks to be completed. Attached Figure Description

[0026] Figure 1This is the core data flow diagram of the vector-based virtual file system interaction method of this invention; Figure 2 This is a complete flowchart of the virtual file system interaction method based on vector retrieval of the present invention; Figure 3 This is a schematic diagram illustrating the continued retrieval and hierarchical convergence within the virtual result directory in the vector-based virtual file system interaction method of the present invention. Detailed Implementation

[0027] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0028] It should be noted that the data in this embodiment are all derived from a comprehensive analysis and evaluation of historical data from the six months prior to this determination and the corresponding historical determination results by the system described in this invention. Those skilled in the art will understand that the system described in this invention can determine the above-mentioned parameters for a single item by selecting the value with the highest proportion based on the data distribution as the preset standard parameter, using weighted summation to obtain the value as the preset standard parameter, substituting each historical data point into a specific formula and using the value obtained by that formula as the preset standard parameter, or other selection methods, as long as the system described in this invention can clearly define different specific situations in the single-item determination process through the obtained values.

[0029] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0030] It should be noted that in the description of this invention, the terms "upper", "lower", "left", "right", "inner", "outer", etc., which indicate directions or positional relationships, are based on the directions or positional relationships shown in the accompanying drawings. This is only for the convenience of description and is not intended to indicate or imply that the device or element must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of this invention.

[0031] Furthermore, it should be noted that, in the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0032] Please see Figures 1-3 As shown, Figure 1 This is the core data flow diagram of the vector-based virtual file system interaction method of this invention; Figure 2 This is a complete flowchart of the virtual file system interaction method based on vector retrieval of the present invention; Figure 3 This is a schematic diagram illustrating the continued retrieval and hierarchical convergence within the virtual result directory in the vector-based virtual file system interaction method of the present invention.

[0033] This embodiment of the virtual file system interaction method based on vector retrieval includes: Step S1: Based on the file metadata of the virtual file system, establish a content semantic index for the files in the virtual file system and store it in a vector database. The content semantic index includes at least file identification information for locating files, the original file path, and vector data obtained by encoding the file content through an encoding model. Step S2: Receive the semantic query request submitted by the user and encode it into a query vector. Perform similarity retrieval in the vector database using the query vector to obtain a set of matching files composed of file identification information. Step S3: Based on the set of matched files, dynamically construct a virtual result directory and generate a corresponding virtual file item for each matched file. The virtual file item includes at least display information and similarity information, and establish a mapping relationship between each virtual file item and the location information of its corresponding real file. Step S4: Present the virtual result directory as a local directory accessible to the operating system through the user-mode virtual file system; Step S5: Intercept the file operation request initiated by the user on the virtual file item in the local directory, obtain the location information of the corresponding real file according to the mapping relationship, and route the operation request to the corresponding real file.

[0034] In this embodiment, step S1, which involves establishing a content semantic index for files in the virtual file system and storing it in a vector database based on the file metadata of the virtual file system, specifically includes: First, the system traverses the files in each workspace directory of the virtual file system, obtains the metadata information of each file, including file path, file name, file type, file size, and last modification time, and calculates a message digest value based on the absolute file path as the unique identifier of the file. For single files whose content length does not exceed a preset block threshold, their unique identifier is equal to the path digest value; for large files whose content length exceeds the block threshold, they are divided into multiple blocks according to a preset block length, and the record identifier of each block is the path digest value concatenated with a separator and a block number. The block threshold is determined based on the available system memory size, taking 1 / 4 of the available memory and not exceeding 10MB; the block length is 1 / 2 of the block threshold.

[0035] Secondly, the system performs differentiated content extraction based on file type: for text files, it directly reads the text content; for image files, it calls a visual language model to first determine the image complexity. In simple images with one or two subjects, the subject descriptions occupy a higher proportion of the text; in complex images with three or more subjects, the subject descriptions are evenly distributed, and the background is represented by keyword tags to generate adaptive descriptive text; for PDF files, it first extracts the embedded text layer. When the number of characters in the extracted text is lower than a preset threshold, it is determined to be a scanned file. The page is then rendered as an image, and optical character recognition is performed. The recognition results are filtered for noise and then concatenated into text content. The preset threshold is determined based on language statistical characteristics: a batch of no less than 1000 PDF files is randomly sampled, and the distribution of the number of characters in their embedded text layer is statistically analyzed. The 30th percentile of the distribution is taken as the judgment threshold to cover the lower limit of the character count for the vast majority of scanned PDFs.

[0036] Then, the system calls the embedding model to encode the extracted text content, generating dense and sparse vectors. The system combines the file's unique identifier, original file path, file metadata, and the encoded vector data into a content semantic index record, which is then written to the vector database. Furthermore, during indexing, the system performs incremental deduplication optimization: it checks the vector database for records prefixed with the current file path digest value to determine if a file has already been indexed. If indexed, it reads the file size and modification time from existing records and compares them with the current file. The file size is compared using exact integers, while the modification time, due to precision loss from being stored as a floating-point number, is compared using a preset tolerance range of seconds. When the file sizes are identical and the modification time difference is within the tolerance range, the file is considered unchanged, and the content extraction and encoding process is skipped. The tolerance range is determined based on the upper limit of floating-point storage precision loss: the modification time is stored as a double-precision floating-point number with a Unix millisecond-level timestamp. The effective number of bits in a double-precision floating-point number is about 15 bits. When the timestamp value reaches the order of 1.7 × 10^9 milliseconds, the unit precision loss is about 0.125 microseconds. However, considering the cumulative error introduced by floating-point operations and the fluctuation of the file system timestamp itself, combined with the maximum observed difference in timestamps of consecutive file operations in actual tests, a tolerance value of 300 seconds is taken. This value covers the normal fluctuation range of floating-point quantification error and timestamp granularity of various file systems.

[0037] Meanwhile, the system provides real-time status tracking: it receives a mixed input list containing file paths and folder paths, recursively expands the folder paths into a flat file list, and writes all files to be processed into the task details as "pending processing" before processing begins; during processing, the status and corresponding count of each file are updated in real time after each file is completed, and the caller can view the current status and processing progress of each file through the polling interface.

[0038] In this embodiment, step S2, which involves receiving a semantic query request submitted by the user and encoding it into a query vector, and then using the query vector to perform a similarity retrieval in the vector database to obtain a set of matching files composed of file identification information, specifically includes: First, the system receives the semantic query request submitted by the user through a virtual file system entry point. The semantic query request includes natural language text queries, image queries, and multimodal queries combining text and images. For natural language text queries, the system directly preprocesses the query text; for image queries, the system extracts the most basic and general category names from the query images using a visual language model. The extraction rules are: if the specific species can be determined, the closest general category word is output; if not, the visible category name is directly output. Outputting color, posture, background, location, quantity, material, or complete sentences is prohibited. After obtaining the category words, the system expands the subject name into the corresponding category words through a local category dictionary. The local dictionary covers the mapping from common species such as animal species, mobile phone brands, car brands, and computer brands to basic categories. If the dictionary does not cover these categories, the system queries through an external interface and caches the results. Finally, a multi-word query text containing the subject name and expanded category words is constructed.

[0039] Secondly, the system calls the same embedding model used during index building to encode the preprocessed query content into query vectors, ensuring that the query vectors and index vectors reside in the same semantic space. Then, the system uses the query vectors as search criteria to perform similarity retrieval in the vector database. A hybrid retrieval strategy combining dense and sparse vectors is employed: dense vector retrieval captures the deep semantic similarity between the query and the file content, while sparse vector retrieval captures precise keyword-level matching. The system fuses the two search results, sorts them by overall similarity from high to low, and truncates them based on a preset Top-K number to filter out matching file records. The Top-K number is determined based on the number of items a single page of the user interface can handle and the user's cognitive load: it is based on the maximum number of items that a normal user cannot cognitively burden in a single browsing session, using Miller's Law of 7±2. Considering that each item in the file list contains multiple pieces of information such as filename, type, size, and similarity score, increasing the cognitive load, a lower limit of 5 (K=7) is used, and the user is allowed to manually adjust this value through the configuration interface. Finally, the system extracts the unique file identifier from each matching file record in the search results, forming a set of matching file identifiers. It also records the similarity score and sorting position information corresponding to each file identifier for use in subsequent step S3 when constructing the virtual results directory. The search scope is limited by default to the vector index set corresponding to the user's current workspace; semantic searches between different workspaces do not interfere with each other.

[0040] This embodiment establishes a semantic index based on existing metadata in the virtual file system. Differentiated content extraction strategies are employed for different file types, such as text, images, and portable documents, enabling high-quality semantic indexes to be built for multimodal files. Incremental deduplication and modification time tolerance comparison skip duplicate processing of unchanged files, improving index building efficiency. Real-time status tracking allows callers to view the processing status and progress of each file at any time. When a user submits a semantic query, the system encodes the query into a vector with the same semantic space as the index and uses a hybrid retrieval strategy to obtain a set of matching files. Image queries construct multi-word queries through category extraction and dictionary expansion, solving the problems of inconsistent terminology in text and image retrieval and decreased accuracy in multi-subject image retrieval. The number of searches is set according to the cognitive load principle to ensure that the results are presented completely on a single page. Therefore, users do not need to know the file path or name; they can obtain a set of semantically matched files based solely on natural language or images. This lays the foundation for constructing an operable virtual directory and achieves integrated interaction from semantic discovery to file access.

[0041] Specifically, the dynamically constructed virtual result directory includes: A virtual directory name is generated based on semantic query information, timestamp, and session identifier; For each matched file, a virtual file item is constructed. The virtual file item includes at least a display name, file identification information, file attribute information, similarity information, original path mapping information, and storage status information. The display name is either the filename of the real file or a semantic name generated based on the query content. The virtual file items are sorted in descending order of similarity information.

[0042] In this embodiment, the system first generates a virtual directory name based on the semantic query information submitted by the user, the current timestamp, and the session identifier. Specifically, the semantic query information is subjected to keyword extraction or summary truncation (the first N characters are truncated, where N is 20. This value is determined based on the file system path length limit; the maximum path length on Windows is 260 characters, while Linux usually has no actual limit but for compatibility considerations, and the optimal length for user recognition is determined; 20 characters can be fully displayed in common file managers and can carry the core semantics of the query). The extracted keywords are concatenated with the timestamp (in YYYYMMDD format) and the short hash value of the session identifier (the first 6 digits are taken, which is long enough to distinguish different sessions within a single day and is not prone to collisions) to generate a virtual directory name in the form of "AI Contract_20260816_a3f9", ensuring that the virtual directories generated by different queries by the same user on the same day do not have the same name.

[0043] Secondly, the system iterates through the file identifier information of each matching file in the set of matching files obtained in step S2, and creates an independent mapping record for each matching file in the virtual file item mapping table. Each mapping record contains at least the following fields: virtual path (composed of a virtual directory name and a file name, such as " / SearchResults / AI Contract_20260816_a3f9 / Annual Report.docx"), session identifier, file unique identifier, display name, original path, similarity score, sorting number, file type, file size, modification time, index status, storage status, and access permissions. Among them, the file unique identifier, file type, file size, modification time, and original path are all read from the content semantic index record established in step S1; the similarity score and sorting number are obtained from the search results in step S2; the index status is obtained from the index status tracking in step S1, with values ​​of ready, pending, or failed; the storage status is determined according to the storage medium type corresponding to the original path, including online, nearline, and offline.

[0044] For determining the display name, the system defaults to using the original filename of the actual file as the display name. When the original filename is a meaningless string or a pure numeric number, the system generates a semantic name based on the query content. Specifically, the system combines keywords from the query information with the original file path and file type to generate a name that is easy for users to recognize. For example, if the original filename is "IMG_20250816_153042.jpg" and the query is "Golden Retriever", the display name generated is "Golden Retriever.jpg". The logic for generating the semantic name is as follows: if the main part of the filename (excluding the extension) is a pure numeric number or a generic meaningless prefix (such as IMG_, PIC_, DSC_, tmp_, etc.), then the query keywords are used to replace the main part of the filename, while the original extension is retained.

[0045] Then, the system sorts the virtual file items in descending order of similarity score. For records with the same similarity score, a second sort is performed based on modification time, from most recent to oldest, ensuring users see the newest and most relevant files first. Finally, the system maintains a set of file identifier information for the current session, storing the unique identifiers of all files corresponding to the current search results in this set, associated with the session identifier, for use as filtering boundaries when continuing searches within the current virtual result directory.

[0046] This embodiment generates semantically meaningful and unique virtual directory names based on query content, timestamps, and session identifiers, enabling users to intuitively identify different search sessions in the file manager. For each matching file, a virtual file item is constructed, containing a display name, file attributes, similarity score, storage status, and original path mapping. When the original file name is a meaningless number, a semantic name is automatically generated using query keywords, significantly improving the readability of search results and user identification efficiency. Virtual file items are sorted in descending order of similarity, and when scores are the same, they are further sorted by modification time, ensuring that the most relevant and up-to-date files are presented first. Simultaneously, the system maintains a set of file identifiers for the current session, providing filtering boundaries for further searches within the directory. This allows multiple rounds of searching to continuously converge within the existing results range without repeatedly traversing the entire database. Throughout the process, virtual file items only store mapping relationships without copying real files. The same file can appear in multiple virtual directories without creating storage redundancy, achieving instant presentation and efficient management of search results.

[0047] Specifically, intercepting user-initiated file operation requests to virtual file items includes at least one of the following: The directory listing operation, if intercepted, queries the mapping relationship and returns a list of attribute information for all virtual file items in the current virtual result directory, without reading the actual file content; If the attribute query operation is intercepted, the attribute information of the corresponding real file is obtained and returned according to the mapping relationship. If the open operation is blocked, the real file is located according to the mapping relationship, and an operation handle is established after permission and availability verification. If a read operation is intercepted, the content is read from the storage location of the real file according to the mapping relationship and returned. If the copy operation is intercepted, the actual file content is retrieved through a read operation and then transferred to the target location.

[0048] In this embodiment, when a user performs operations on virtual file items in the virtual result directory through the operating system file manager, command-line tools, or third-party applications, the user intercepts the corresponding file system calls in the virtual file system adaptation layer and performs corresponding routing processing according to the operation type.

[0049] For directory listing operations: When a user opens a virtual results directory or executes a command to list directory contents, the system intercepts the directory listing request, queries all virtual file item records under the current session identifier in the virtual file item mapping table, and directly returns a list of attribute information for each record, including the virtual file name, file type, file size, modification time, and similarity score. During this process, the system only reads the mapping table and does not trigger any access to the actual file storage medium. Therefore, even if the actual file is offline or archived, the user can still instantly see the complete list of search results.

[0050] For attribute query operations: When a user views the attributes of a virtual file item, the system intercepts the attribute query request. Based on the file's unique identifier and original path in the mapping record of the virtual file item, the system queries the underlying storage system for the metadata of the corresponding real file. The returned attribute information, such as file size, modification time, file type, storage status, and access permissions, along with the similarity score recorded in the mapping table, is presented to the user, allowing the user to understand the complete attributes of the file before opening it.

[0051] For the open operation: When a user double-clicks a virtual file item, the system intercepts the open request, obtains the file's unique identifier and original path based on the mapping record, first checks the user's access permissions to the real file, then checks the file's availability status, and after both permission and status checks pass, establishes a read handle and returns it to the operating system, which the application can then use to initiate a read request.

[0052] For read operations: When an application performs a read operation on an opened virtual file item, the system intercepts the read request, reads the specified range of data from the storage medium of the real file based on the file's unique identifier and storage location corresponding to the handle established during the open operation, and returns it to the application in the form of a data stream. The entire read process is completely transparent to the application.

[0053] For copy operations: When a user copies a virtual file item to another directory, the system intercepts the copy request, obtains the full content of the real file through continuous open and read operations, and transmits the file data stream to the target location. What the user perceives is a file being copied from the virtual result directory, but what is actually transmitted is the complete content of the real file.

[0054] In all the above operations, the system automatically locates the real files and accesses data at the underlying level based on the mapping relationship. Users do not need to know the actual storage path of the files. The operation method for files in the virtual result directory is exactly the same as that for ordinary folders. Existing applications can be used in a compatible manner without any modifications.

[0055] Specifically, the virtual results directory is set to read-only mode by default: Allow users to browse, open, and copy virtual file items, but prohibit write, delete, and rename operations; When it is necessary to modify the original file, guide the user to perform the modification operation through the directory where the original file is located; When the same real file appears in multiple virtual result directories, deleting a virtual file item in any virtual result directory only removes the current mapping relationship and does not delete the real file.

[0056] In this embodiment, when a user performs operations on virtual file items in the virtual results directory, the system intercepts permissions at the user-mode virtual file system adaptation layer. The system allows users to perform browse, open, and copy operations, but prohibits write, delete, and rename operations. Specifically, for write operations, the system intercepts the operation and returns a "read-only file system" error code, prompting the user that "the search results directory is read-only; please go to the directory where the original file is located if you need to modify it." For delete and rename operations, the system similarly intercepts them and returns a permission denied prompt. When a user does need to modify the original file, the system guides the user in the following ways: by including the complete path information of the original file in the returned permission prompt, guiding the user to the workspace directory where the original file is located to perform the modification operation, or by explicitly mapping the modification operation to the original file through permission policies before execution. This design avoids data loss caused by accidental operations in the virtual results directory.

[0057] When the same real file appears in multiple virtual result directories due to responses to different semantic queries, the system maintains an independent mapping record for each occurrence in the virtual file item mapping table. All mapping records point to the same unique file identifier. When a user performs a deletion operation in a virtual result directory, the system only removes the corresponding mapping record in that virtual result directory, without affecting the mapping records in other virtual result directories, and without deleting the real file itself. Only when the user performs a deletion operation on a real file in the original working directory will the system synchronously clean up the index records in the vector database and the mapping relationships in all virtual result directories.

[0058] Specifically, this also includes continuing the search within the current virtual results directory and managing multiple directory mappings: The system maintains the search session state, creating a session identifier and storing a set of file identifier information corresponding to the current search results upon the first search. Receive a user's request to continue searching within the current virtual results directory, and use the set of file identifier information as a filter condition to ensure that the search is only performed within that set. After the search is completed, a sub-virtual result directory is generated or the current virtual result directory is updated, and the stored file identification information set is updated. Each round of search uses the file identification information set of the previous round of results as the filtering boundary, forming a hierarchical virtual result directory system. When the same real file appears in different virtual result directories due to responses to different semantic queries, the system creates an independent mapping record for each occurrence, and each mapping record points to the location information of the same real file.

[0059] In this embodiment, the system maintains the search session state on the server side. When a user submits a semantic query for the first time, the system creates a session identifier and assigns an expiration period. It then performs a search across the entire vector database, obtains a set of matching file identifiers, associates and stores this set with the session identifier, and generates a virtual results directory to present to the user.

[0060] When a user submits new search criteria in the virtual results directory, the system retrieves the file identifier set from the previous round based on the session identifier. This set is then used as a filter for vector retrieval, ensuring that the new round of retrieval is performed only within this set. Specifically, the system adds a file identifier list filter to the query criteria in the vector database, performing similarity calculations and sorting only on index records matching this identifier list, thus achieving precise convergence of the result range. After the retrieval is completed, the system generates a sub-virtual results directory name based on the new query criteria, constructs the sub-virtual directory and mounts it to the current directory, forming a hierarchical directory structure, and updates the file identifier set in the session state to the current round's result set. Each subsequent retrieval uses the file identifier set from the previous round as the filter boundary, allowing users to perform multiple rounds of progressive convergence until the search results precisely match their needs.

[0061] In terms of multi-directory mapping management, the system records the correspondence between each virtual file item and its real file through a virtual file item mapping table. When the same real file appears in multiple virtual result directories due to responses to different semantic queries, the system creates an independent mapping record for each occurrence in the mapping table. Each mapping record records its own session identifier, virtual path, and similarity score, but all mapping records point to the same unique file identifier. This many-to-one mapping mechanism ensures that only one copy of the real file needs to be stored, eliminating redundant copies caused by its appearance in multiple search results. Furthermore, deleting a mapping record in any virtual directory only affects the current view and does not affect mapping records in other directories or the real file itself.

[0062] This embodiment maintains session state and file identifier set, enabling users to continuously submit new search conditions within the current virtual result directory. Each round of retrieval uses the file identifier set of the previous round's results as the filtering boundary, and the search scope converges round by round without repeatedly traversing the entire database. The search efficiency increases significantly with each round. At the same time, each round of retrieval generates a sub-virtual directory and mounts it to the current directory, forming a hierarchical directory structure from coarse to fine. Users can trace the search path along the directory hierarchy and intuitively understand the result convergence process. In terms of multi-directory mapping, the system creates independent mapping records for each appearance of the same real file in different virtual result directories through a mapping table. All records point to the same unique file identifier, so that the file only needs to be stored once and can be repeatedly presented in multiple semantic query results without any storage redundancy. Moreover, the deletion operation in any virtual directory only removes the mapping record of the current view and does not affect the presentation in other directories or the real file itself. Thus, while achieving multi-view organization and zero-redundancy storage of search results, it ensures data security and operational semantic consistency in multi-view scenarios.

[0063] Specifically, this also includes an index synchronization and maintenance mechanism based on operation logs: When a file in the virtual file system is modified, the system generates a corresponding file event and writes it to the operation log; When a file is created, an index is built after the content is written to disk and the index status is marked as ready; When a file is modified, first delete all old index records of the file in the vector database, then re-extract the content, encode it, and write it into a new record. After completion, set the index status to ready and mark the relevant virtual file items as pending refresh. If re-indexing fails, retain the previous version of the index record. When deleting a file, first lock the file identification information to prevent concurrent indexing operations, and then clear the index records and all mapping relationships; The virtual results directory displays virtual file items with an indexed status of "ready," and displays the corresponding status identifier for virtual file items with an indexed status of "pending" or "failed."

[0064] In this embodiment, when a file in the virtual file system undergoes a change operation such as creation, modification, or deletion, the system first generates the corresponding file event and writes it to the operation log for persistent recording, and then performs the corresponding index synchronization operation according to the change type.

[0065] For file creation operations: After the file content is written to disk, the system sets the index status to pending, initiates the content extraction and vector encoding process, calls the embedding model to encode the extracted text content to generate dense and sparse vectors, constructs index records containing file metadata and vector data and writes them to the vector database, and marks the index status as ready upon completion. If an exception occurs during content extraction or encoding, the index status is marked as failed and the reason for the failure is recorded in the operation log.

[0066] For file modification operations: The system first sets the index status to "updating," then deletes all old index records for that file from the vector database by matching the file's unique identifier prefix. Next, it re-extracts, encodes, and writes the content to new records according to the file creation process. Once completed, the index status is set to "ready," and the virtual file entry for that file in the relevant virtual result directory is marked as "pending refresh." The latest file attributes will be automatically displayed the next time the user opens the corresponding virtual directory. If an exception occurs during the re-indexing process, the index status is reset to "failed," but the previous version of the index records is retained for retrieval, ensuring uninterrupted retrieval service during modification.

[0067] For file deletion operations: The system first locks the file's unique identifier to prevent concurrent index operations from accessing the file, then deletes all index records of the file in the vector database by matching the file's unique identifier prefix, simultaneously queries the virtual file item mapping table to delete all mapping records pointing to the file's unique identifier, cleans up the file's view in all virtual result directories, and finally releases the file lock.

[0068] When displaying the file list, the virtual results directory only shows virtual file items with an indexed ready status in a normal state; for virtual file items with an indexed pending or failed status, the corresponding status indicator is displayed in the virtual results directory to inform the user of the file's index availability.

[0069] This embodiment achieves synchronous maintenance of file system operations and semantic indexes through the transaction mechanism of operation logs and state machines, effectively avoiding the window period of inconsistency between file changes and indexes. At the same time, through file locking mechanism and old version retention strategy, the security of index operations and the continuity of retrieval services are guaranteed while ensuring consistency.

[0070] Specifically, the establishment of the content semantic index includes the extraction of differentiated content from different types of files: For text files, the text content is directly extracted and encoded. For image files, during indexing, the complexity of the image is determined by a visual language model, and the length of the description is adaptively allocated according to the number of subjects. In simple images with one or two subjects, the subject descriptions account for a higher proportion of the text, while in complex images with three or more subjects, the subject descriptions are evenly distributed. The background is uniformly represented by keyword tags, and the generated descriptive text is then encoded. During retrieval, if the semantic query request submitted by the user is for an image, the basic general category name is extracted from the query image through the visual language model, and then the subject name is expanded into the corresponding category word through the local category dictionary to construct a multi-word query containing the subject name and category word for semantic retrieval.

[0071] In this embodiment, for text files, the system directly reads the file content and extracts the plain text. After removing formatting tags and invisible characters, the extracted plain text is used as the content text input to the embedding model for vector encoding. For image files, different processing strategies are used in the indexing and retrieval stages. During indexing, the system calls a visual language model to analyze the image. First, it determines the complexity of the image by detecting the number of subjects in the image: if the image contains one or two subjects, it is considered a simple image. When generating the description, each subject is assigned more sentences to describe its key visual features in detail, and the subject description occupies a high proportion of the description text. The background is only briefly represented by comma-separated keyword tags. If the image contains three or more subjects, it is considered a complex image. The descriptions of each subject are evenly distributed, with each subject described using fewer sentences. The background is also represented by keyword tags, without detailed description. After generating adaptive description text, the system inputs the description text into the embedding model for vector encoding and stores it in the index.

[0072] During retrieval, if the user submits a semantic query request for an image, the system first extracts the most basic, general category name from the query image using a visual language model, rather than the specific species or model name. The extraction rules are: if the specific species can be identified, the closest general category term is output; otherwise, the visible category name is output directly. Outputting color, posture, background, location, quantity, material, or complete sentences is prohibited. After obtaining the category term, the system expands the subject name into the corresponding category term using a local category dictionary. The local category dictionary covers the mapping from common species to basic categories, including at least animal species, mobile phone brands, car brands, and computer brands. If the local dictionary does not cover the category, the system queries its category through an external interface and caches the query results. When the external interface is unavailable, the subject name is used directly as the query text. Finally, the system constructs a multi-word query text containing the subject name and category term, encodes it, and then performs semantic retrieval.

[0073] Specifically, this also includes automatic identification of scanned documents and optical character recognition as a fallback: The embedded text layer is first extracted from the PDF file. If the amount of extracted text is lower than a preset threshold, the file is determined to be a scanned file. After rendering the pages of the scanned document into an image, optical character recognition is performed. After filtering out noisy lines from the recognition results, the concatenated text is indexed as the file content. The noisy line filtering includes filtering lines consisting of pure whitespace or separators, as well as lines with a length less than a preset value and containing no Chinese characters. When the total number of pages in the document exceeds the page limit, only the first preset number of pages will be processed, and a truncation prompt will be added to the end of the text.

[0074] In this embodiment, for PDF files, the system first uses a text extraction tool to extract the embedded text layer and counts the total number of extracted characters. When the amount of extracted text is lower than a preset threshold, the system automatically determines that the PDF is a scanned file; if the amount of extracted text is not lower than the threshold, it is determined to be a normal text-based PDF, and the extracted text content is directly used as the file content for indexing, without triggering subsequent rendering and optical character recognition processes, ensuring zero additional processing overhead for normal files. The preset threshold is determined by randomly sampling a batch of no less than one thousand PDF files, statistically analyzing the distribution of the number of characters in their embedded text layer, and taking the 30th percentile of the distribution as the determination threshold to cover the lower limit of the number of characters for the vast majority of scanned PDFs.

[0075] After identifying the document as a scanned file, the system uses a PDF rendering library to render each page of the document as a grayscale image at a preset number of dots per inch (dpi). The rendering parameters are dynamically adjusted based on the page width: when the page width is less than a first preset size, the parameters are automatically increased to the first value to ensure small character recognition accuracy; when the page width is greater than a second preset size, the parameters are automatically decreased to the second value to save processing time. After rendering, the system uses an optical character recognition (OCR) engine to recognize each page of the image one by one. The engine employs a lazy loading strategy, initializing the recognition model only when the scanned file processing is triggered for the first time. After successful loading, the engine instance is cached as a singleton for reuse, and subsequent pages and subsequent files share the same instance. If the engine fails to load due to missing dependencies or other reasons, this failure status is permanently marked, and subsequent scanned files will not attempt to initialize it, directly returning empty content and logging the error.

[0076] For each page of the image recognition results, the system performs noise filtering line by line. The noise line determination follows these rules: First, it checks if the line text matches a pure delimiter pattern, i.e., it consists only of one or more of the following: whitespace, vertical bar, hyphen, underscore, equal sign, plus sign, asterisk, tilde, and period. If it does not match a pure delimiter pattern, it checks if the line text length is less than a preset value and does not contain any Chinese characters. Lines meeting any of these conditions are discarded, and the remaining lines are retained. After recognition, the system concatenates the filtered text from each page, inserting a marker line containing page numbers before each page, and separating pages with blank lines. When the total number of pages in the file exceeds the page limit, the system only processes the first preset number of pages and appends a truncation warning to the end of the concatenated text. This truncation warning participates in subsequent vector encoding, enabling users to know that there are unindexed pages in the file during semantic retrieval.

[0077] This embodiment first extracts the embedded text layer from portable documents, automatically determines the file type based on statistical thresholds, and directly uses the extracted text for normal files with zero additional overhead. Scanned files are converted into indexable text through rendering and recognition, achieving differentiated processing of mixed file sets. Rendering parameters are dynamically adjusted according to page width, balancing recognition rate and processing efficiency. The recognition engine uses lazy loading and singleton reuse to avoid repeated initialization overhead, and permanently marks failed loading attempts to prevent retrying, ensuring system stability. Noise line filtering effectively removes invalid noise through dual judgment of delimiter mode and character, improving the quality of indexed text. When the page limit is exceeded, only the beginning is processed and a truncation prompt is added for encoding, allowing users to know the index coverage range, thereby converting scanned files into searchable content and significantly expanding the file coverage of the semantic retrieval system.

[0078] Specifically, this also includes incremental deduplication and real-time status tracking: When building a semantic index for content, the hash value of the path of the file to be indexed is used as a record identifier prefix. The existence of a record with this prefix in the vector database is used to determine whether the file has been indexed. If the file is already indexed, the file size and modification time stored in the record are compared with the current file. The file size is compared with an integer for precision, while the modification time is compared with a preset tolerance range of seconds because it is stored as a floating-point number and there is a loss of precision. When the file sizes are the same and the difference in modification time is within the tolerance range, the re-encoding process of the file is skipped. It accepts a mixed input list containing file paths and folder paths, and recursively expands the folder paths into a flat list of files; Before starting file-by-file processing, all files to be processed are written to the task details with a preset status. During the processing, the status and count of each file are updated in real time after each file is completed. The processing status values ​​include success, failure, skipped, and pending.

[0079] In this embodiment, when building a content semantic index, the system uses the absolute path of the file to be indexed to calculate a hash value as a record identifier prefix. For a single file whose content length does not exceed a preset block threshold, its record identifier is equal to the path hash value; for a large file whose content length exceeds the block threshold, its content is divided into multiple blocks according to a preset block length, and the record identifier of each block is the path hash value concatenated with a separator and a block number. The system determines whether a file has been indexed by querying the vector database to see if there is a record with that path hash value as a prefix.

[0080] If the query returns zero records, it means the file has never been indexed, and the content extraction and encoding process proceeds directly. If the query returns a greater than zero record, it means the file has been indexed. The file size and last modified time are then read from existing records and compared with the current file. The file size field is stored as an integer for precise comparison; the modification time field is stored as a floating-point number, resulting in some precision loss, but a preset tolerance range of seconds is used for comparison. When the file sizes are exactly equal and the absolute value of the modification time difference does not exceed the tolerance range, the file is determined to be unchanged, and the content extraction and encoding process is skipped, directly marking it as skipped.

[0081] During index building, the system also provides real-time status tracking. The system receives a mixed input list containing file paths and folder paths, recursively traverses the folder paths, expands them into a flat list of file paths, and records the source input path for each file. Before starting file-by-file processing, the system writes all files to be processed into the task details with a preset pending status. Each file record includes four fields: file path, source input, current status, and error information. During processing, the system updates the status and corresponding count of each file in real time upon completion. The processing status values ​​include: success (content extraction and encoding completed); failure (processing error, with specific error information recorded); skipped (incremental deduplication determines no changes and no need for reprocessing); and pending (processing has not yet started). The caller can view the current status, source folder, and processing progress of each file during the processing by polling the interface.

[0082] This embodiment significantly improves index building efficiency by skipping duplicate processing of unchanged files while ensuring index accuracy through incremental deduplication and real-time status tracking mechanisms. At the same time, it allows the caller to know the processing status and progress of each file in real time during the processing without waiting for all tasks to be completed.

[0083] Specifically, a system applied to the vector-based virtual file system interaction method includes: The semantic indexing module is used to store file identification information, original file path, and vector data obtained by encoding the file content through an encoding model as a unified content semantic index based on the file metadata of the virtual file system. The vector retrieval module is used to receive semantic query requests and encode them into query vectors, and perform similarity retrieval in the vector database based on the query vectors to obtain a set of matching files composed of file identification information; The virtual directory generation module is used to dynamically construct a virtual result directory based on the set of matched files, generate a virtual file item for each matched file, and establish a mapping relationship between each virtual file item and the location information of its corresponding real file. The virtual file system adaptation module is used to present the virtual result directory as a local directory accessible to the operating system through the user-mode virtual file system, and to intercept file operation requests initiated by the user on the virtual file items. The file operation routing module is used to route the intercepted file operation requests to the corresponding real files according to the mapping relationship and return the file content or attribute information.

[0084] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0085] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A virtual file system interaction method based on vector retrieval, characterized in that, include: Step S1: Based on the file metadata of the virtual file system, establish a content semantic index for the files in the virtual file system and store it in a vector database. The content semantic index includes at least file identification information for locating files, the original file path, and vector data obtained by encoding the file content through an encoding model. Step S2: Receive the semantic query request submitted by the user and encode it into a query vector. Perform similarity retrieval in the vector database using the query vector to obtain a set of matching files composed of file identification information. Step S3: Based on the set of matched files, dynamically construct a virtual result directory and generate a corresponding virtual file item for each matched file. The virtual file item includes at least display information and similarity information, and establish a mapping relationship between each virtual file item and the location information of its corresponding real file. Step S4: Present the virtual result directory as a local directory accessible to the operating system through the user-mode virtual file system; Step S5: Intercept the file operation request initiated by the user on the virtual file item in the local directory, obtain the location information of the corresponding real file according to the mapping relationship, and route the operation request to the corresponding real file.

2. The method according to claim 1, characterized in that, The dynamically constructed virtual result directory includes: A virtual directory name is generated based on semantic query information, timestamp, and session identifier; For each matched file, a virtual file item is constructed. The virtual file item includes at least a display name, file identification information, file attribute information, similarity information, original path mapping information, and storage status information. The display name is either the filename of the real file or a semantic name generated based on the query content. The virtual file items are sorted in descending order of similarity information.

3. The method according to claim 1, characterized in that, The interception of user-initiated file operation requests to virtual file items includes at least one of the following: The directory listing operation, if intercepted, queries the mapping relationship and returns a list of attribute information for all virtual file items in the current virtual result directory, without reading the actual file content; If the attribute query operation is intercepted, the attribute information of the corresponding real file is obtained and returned according to the mapping relationship. If the open operation is blocked, the real file is located according to the mapping relationship, and an operation handle is established after permission and availability verification. If a read operation is intercepted, the content is read from the storage location of the real file according to the mapping relationship and returned. If the copy operation is intercepted, the actual file content is retrieved through a read operation and then transferred to the target location.

4. The method according to claim 1, characterized in that, The virtual results directory is set to read-only mode by default. Allow users to browse, open, and copy virtual file items, but prohibit write, delete, and rename operations; When it is necessary to modify the original file, guide the user to perform the modification operation through the directory where the original file is located; When the same real file appears in multiple virtual result directories, deleting a virtual file item in any virtual result directory only removes the current mapping relationship and does not delete the real file.

5. The method according to claim 1, characterized in that, It also includes continuing the search within the current virtual results directory and managing multiple directory mappings: The system maintains the search session state, creating a session identifier and storing a set of file identifier information corresponding to the current search results upon the first search. Receive a user's request to continue searching within the current virtual results directory, and use the set of file identifier information as a filter condition to ensure that the search is only performed within that set. After the search is completed, a sub-virtual result directory is generated or the current virtual result directory is updated, and the stored file identification information set is updated. Each round of search uses the file identification information set of the previous round of results as the filtering boundary, forming a hierarchical virtual result directory system. When the same real file appears in different virtual result directories due to responses to different semantic queries, the system creates an independent mapping record for each occurrence, and each mapping record points to the location information of the same real file.

6. The method according to claim 1, characterized in that, It also includes an index synchronization and maintenance mechanism based on operation logs: When a file in the virtual file system is modified, the system generates a corresponding file event and writes it to the operation log; When a file is created, an index is built after the content is written to disk and the index status is marked as ready; When a file is modified, first delete all old index records of the file in the vector database, then re-extract the content, encode it, and write it into a new record. After completion, set the index status to ready and mark the relevant virtual file items as pending refresh. If re-indexing fails, retain the previous version of the index record. When deleting a file, first lock the file identification information to prevent concurrent indexing operations, and then clear the index records and all mapping relationships; The virtual results directory displays virtual file items with an indexed status of "ready," and displays the corresponding status identifier for virtual file items with an indexed status of "pending" or "failed." 7. The method according to claim 1, characterized in that, The establishment of the content semantic index includes the extraction of differentiated content from different types of files: For text files, the text content is directly extracted and encoded. For image files, during indexing, the complexity of the image is determined by a visual language model, and the length of the description is adaptively allocated according to the number of subjects. For simple images with one or two subjects, the subject descriptions account for a higher proportion of the text, while for complex images with three or more subjects, the subject descriptions are evenly distributed. The background is uniformly represented by keyword tags, and the generated descriptive text is then encoded. During retrieval, if the semantic query request submitted by the user is an image, the basic general category name is extracted from the query image through the visual language model, and then the subject name is expanded into the corresponding category word through the local category dictionary to construct a multi-word query containing the subject name and category word for semantic retrieval.

8. The method according to claim 1, characterized in that, It also includes automatic identification of scanned documents and optical character recognition as a fallback: The embedded text layer is first extracted from the PDF file. If the amount of extracted text is lower than a preset threshold, the file is determined to be a scanned file. After rendering the pages of the scanned document into an image, optical character recognition is performed. After filtering out noisy lines from the recognition results, the concatenated text is used as the file content for indexing. The noisy line filtering includes filtering lines consisting of pure whitespace or separators, as well as lines with a length less than a preset value and containing no Chinese characters. When the total number of pages in the document exceeds the page limit, only the first preset number of pages will be processed, and a truncation prompt will be added to the end of the text.

9. The method according to claim 1, characterized in that, It also includes incremental deduplication and real-time status tracking: When building a semantic index for content, the hash value of the path of the file to be indexed is used as a record identifier prefix. The existence of a record with this prefix in the vector database is used to determine whether the file has been indexed. If the file is already indexed, the file size and modification time stored in the record are compared with the current file. The file size is compared with an integer for precision, while the modification time is compared with a preset tolerance range of seconds because it is stored as a floating-point number and there is a loss of precision. When the file sizes are the same and the difference in modification time is within the tolerance range, the re-encoding process of the file is skipped. It accepts a mixed input list containing file paths and folder paths, and recursively expands the folder paths into a flat list of files; Before starting file-by-file processing, all files to be processed are written to the task details with a preset status. During the processing, the status and count of each file are updated in real time after each file is completed. The processing status values ​​include success, failure, skipped, and pending.

10. A system for applying the vector-based virtual file system interaction method according to any one of claims 1-9, characterized in that, include: The semantic indexing module is used to store file identification information, original file path, and vector data obtained by encoding the file content through an encoding model as a unified content semantic index based on the file metadata of the virtual file system. The vector retrieval module is used to receive semantic query requests and encode them into query vectors, and perform similarity retrieval in the vector database based on the query vectors to obtain a set of matching files composed of file identification information; The virtual directory generation module is used to dynamically construct a virtual result directory based on the set of matched files, generate a virtual file item for each matched file, and establish a mapping relationship between each virtual file item and the location information of its corresponding real file. The virtual file system adaptation module is used to present the virtual result directory as a local directory accessible to the operating system through the user-mode virtual file system, and to intercept file operation requests initiated by the user on the virtual file items. The file operation routing module is used to route the intercepted file operation requests to the corresponding real files according to the mapping relationship and return the file content or attribute information.

Images