Document version evolution relation analysis method and device based on data consanguinity

Abstract

The invention discloses a document version evolution relation analysis method and device based on data consanguinity. The method comprises the following steps: receiving a version creation request for a preset document library; according to the parent version, determining a potential evolution path of the version to be created, and executing multi-dimensional quantity control check based on the potential evolution path; when the multi-dimensional quantity control check is passed, creating a to-be-created version, and generating a composite version serial number for the to-be-created version; configuring a hierarchical saving state for the to-be-created version to obtain a target document version, and determining a quality evaluation index associated with the target document version based on the composite version serial number; according to the quality evaluation index and a preset weighting model, calculating a comprehensive recommendation score of the target document version; and according to the comprehensive recommendation score, determining a final version from a plurality of target document versions stored in a document library. By implementing the technical scheme, the version management spanning from simple recording to intelligent recommendation is realized, and the collaboration efficiency and the data utilization value are improved.

Description

Technical Field

[0001] This application relates to the technical field of data processing, specifically to a method and apparatus for analyzing document version evolution relationships based on data lineage. Background Technology

[0002] In collaborative scenarios such as document creation and software development, existing version control technologies aim to achieve accurate recording and traceability of file changes. These technologies typically construct a linear or branching chain of version history by storing a complete snapshot of the file at the time of each commit or recording the incremental differences between the current version and the previous version. Each version is assigned a simple serial number, such as v1.0, v1.1, or a unique hash value as an identifier. This mechanism allows users to clearly view the content of any historical version and restore the document to any node in the history when needed, thus ensuring data traceability and integrity.

[0003] However, the aforementioned mechanism, centered on precise recording, has inherent technical flaws in managing and utilizing version data. First, because the system treats all changes indiscriminately, versions that significantly revise core arguments are indiscriminately mixed with minor changes that only correct a few spelling errors, resulting in a large number of redundant and low-value intermediate versions. Second, simple version identification fails to reflect the logical evolution of versions within the creative process, making it extremely difficult to trace the evolution from initial draft to revised draft to final version. Therefore, when it is necessary to sift through a massive, undifferentiated version history to select a representative, high-quality final version, users are forced to rely on subjective experience for manual browsing and selection. This process is not only inefficient but also makes it difficult to guarantee the objectivity and consistency of the results. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a method and apparatus for analyzing document version evolution relationships based on data lineage.

[0005] The first aspect of this application provides a document version evolution relationship analysis method based on data lineage, which adopts the following technical solution: Receive a version creation request for a preset document library, wherein the version creation request is used to specify a parent version; Based on the parent version, determine the potential evolution path of the version to be created, and perform multi-dimensional quantity control checks based on the potential evolution path; When the multi-dimensional quantity control check passes, the version to be created is created, and a composite version serial number is generated for the version to be created. The composite version serial number encodes the complete evolution path from the root version to the version to be created. The root version refers to a version that does not have a parent version. Configure a hierarchical storage status for the version to be created, obtain the target document version, and determine the quality assessment index associated with the target document version based on the composite version serial number; Based on the quality assessment indicators and the preset weighted model, calculate the comprehensive recommendation score for the target document version; Based on the comprehensive recommendation score, the final version is determined from multiple target document versions stored in the document library.

[0006] By adopting the above technical solutions, the problem of version identifiers failing to reflect logical evolution relationships is effectively solved, making the creative path from the root version to the current version clearly traceable. Through multi-dimensional quantity control checks and quality evaluation indicators, version creation is screened and quantitatively evaluated, reducing the generation of redundant intermediate versions and ensuring the simplicity and high quality of the version repository. Finally, based on a weighted model, a comprehensive recommendation score is calculated, and the final version is automatically and objectively determined from multiple versions, avoiding the subjectivity and inefficiency of manual screening. This achieves a leap from simple recording to intelligent recommendation in version management, improving collaboration efficiency and data utilization value.

[0007] Optionally, the step of determining the potential evolution path of the version to be created based on the parent version, and performing a multi-dimensional quantity control check based on the potential evolution path, includes: The number of first versions in all versions of the document library is counted. If the number of first versions exceeds the preset full tree threshold, the multi-dimensional quantity control check is deemed to have failed. The number of second versions in all versions of the potential evolutionary path is counted. If the number of second versions exceeds a preset single-chain threshold, the multi-dimensional quantity control check is deemed to have failed. Identify adjacent evolutionary stages in the potential evolutionary path and count the number of third versions of all versions between the adjacent evolutionary stages. If the number of third versions exceeds a preset stage threshold, the multi-dimensional quantity control check is deemed to have failed.

[0008] By adopting the above technical solution, refined quantity control of version creation is implemented from three dimensions: global, path, and local. Globally, a preset full-tree threshold check prevents the unlimited expansion of the total number of versions in the document repository, avoiding an overly bloated version tree. Path-wise, a preset single-chain threshold limits the number of versions on a single evolutionary path, effectively suppressing the generation of excessively long version chains and maintaining the clarity of the evolutionary mainline. Locally, by identifying adjacent evolutionary stages and setting stage thresholds, excessive minor changes are prevented from being repeatedly submitted within the same creation stage, ensuring the consistency of the version evolution logic. These three dimensions of checks work together to systematically reduce the number of redundant and low-value versions from the source, laying a solid foundation for the automatic selection of high-quality versions, thereby solving the core problems of version mixing and unclear context.

[0009] Optionally, configuring a hierarchical storage status for the version to be created to obtain the target document version includes: Add the hierarchical storage state to the data structure of the version to be created, and set the initial value of the hierarchical storage state attribute to temporary storage state; Based on the temporary storage state, a timed cleanup rule is configured for the version to be created. The timed cleanup rule cleans up document versions that are in the temporary storage state and have exceeded the preset storage duration. The version to be created, which has been given the layered storage status and configured with the timed cleanup rules, will be used as the target document version.

[0010] By adopting the above technical solution and introducing hierarchical storage status and timed cleanup rules, the problems of wasted storage resources and mixed version value in version management are effectively solved. Newly created versions are automatically set to a temporary storage status and associated with their duration. The system can automatically identify and clean up versions that have been in a temporary state for a long time, which realizes the automated screening and release of storage space for low-value or intermediate versions. This mechanism not only optimizes storage resources, but also highlights the importance of high-quality versions actively retained by users through status hierarchies, thereby improving the simplicity and usability of the version repository as a whole, and laying a clean and high-quality data foundation for accurate recommendation of the final version.

[0011] Optionally, the method further includes: Receive a setting instruction, which specifies the version to be solidified, wherein the version to be solidified is one or more of the target document versions stored in the document library; Change the layered save status of the version to be solidified to manual permanent save status, and clear the timed cleanup rules associated with the version to be solidified; The specific complete evolution path of the version to be solidified is obtained by parsing the composite version serial number of the version to be solidified, and the hierarchical storage status of all upstream versions contained in the specific complete evolution path is set to automatic permanent storage status and the timed cleanup rules associated with all upstream versions are cleared.

[0012] By adopting the above technical solution, this application provides an intelligent and efficient version solidification mechanism. When a user manually saves a critical version (the version to be solidified) permanently, the system not only protects the version itself but also intelligently traces its complete evolution path, automatically promoting all upstream versions along the path to permanent storage. This design cleverly solves the problem of associated protection in version management, respecting the user's subjective marking of important achievements while ensuring through system automation that critical evolution history is not accidentally deleted. It not only prevents the loss of important historical versions but also preserves immutable and coherent original data for subsequent data analysis, version auditing, and quality traceability by solidifying the complete evolution chain, greatly improving the reliability of the version repository and the integrity of its historical context.

[0013] Optionally, determining the quality assessment metrics associated with the target document version based on the composite version serial number includes: Obtain the AI ​​detection rate and manual review status of the target document version; Based on the content data of the target document version and the content data of the parent version of the target document version, calculate the content difference degree, and determine the intensity of manual modification based on the content difference degree; The content data of the target document version is analyzed to obtain content structure parameters, and the completeness and standardization of the content are determined based on the content structure parameters through a preset multi-indicator weighting rule. Based on the composite version sequence number, determine the depth of the complete evolution path and the number of sibling versions of sibling versions that have the same parent version as the target document version, and obtain the link simplicity based on the depth and the number of sibling versions through a preset complexity calculation formula. The number of all documents in the document library with the target document version as the parent version is counted, and the number is determined as the number of references in downstream versions. The importance of being referenced is determined based on the number of references in downstream versions. Calculate the time difference based on the creation time of the target document version and the current system time, and determine the time freshness based on the time difference and a preset function; The quality assessment index is obtained by combining the AI ​​detection rate, the status of manual review, the intensity of manual modification, the completeness and standardization of content, the simplicity of the link, the importance of citation, and the freshness of time.

[0014] By adopting the above technical solution and integrating a seven-dimensional evaluation system that considers AI detection rate, manual review status, intensity of manual modifications, completeness and standardization of content, simplicity of the data flow, importance of citations, and timeliness, a comprehensive, automated, and quantitative evaluation of document version value is achieved. This system can accurately identify high-quality versions that are highly original, compliant, standardized in content, have a clear evolution path, and are timely. This allows for the efficient selection of high-purity, low-noise structured data sources for downstream applications such as AI model training, significantly improving the objectivity and intelligence of data extraction.

[0015] Optionally, calculating the content difference based on the content data of the target document version and the content data of the parent version of the target document version includes: Using a preset text vectorization model, the content data of the target document version and the content data of the parent version of the target document version are converted into target content vector and parent content vector, respectively. Calculate the cosine similarity between the target content vector and the parent content vector to obtain a similarity value; Based on the similarity value, the content difference is determined using a preset difference conversion function.

[0016] By employing the aforementioned technical solution, a leap from surface-level character comparison to deep semantic analysis is achieved, enabling precise quantification of the degree of content changes between versions. This method converts document content into vector representations in a high-dimensional space using a text vectorization model, capturing deep semantic features such as grammatical structure and contextual information. By calculating cosine similarity, it accurately measures the semantic similarity between two versions. Finally, a difference conversion function intuitively converts the similarity into content difference. This technical approach effectively overcomes the limitations of traditional character-matching-based difference comparison methods (such as calculating edit distance), intelligently identifying whether versions have undergone substantial, large-scale content reconstruction and evolution of viewpoints, or merely minor adjustments to wording or formatting. This provides precise data support for subsequent objective evaluation of version value and selection of key revision nodes.

[0017] Optionally, the method further includes: Select multiple sibling versions with the same parent version from the document library as candidate versions to be merged. Calculate the content similarity between any two versions in the candidate versions to be merged, and if the content similarity is higher than a preset merging threshold, determine the version with the higher comprehensive recommendation score among the two versions as the retained version, and determine the version with the lower comprehensive recommendation score among the two versions as the archived version; Update the status identifier of the archived version to "merged", release the storage space occupied by the archived version, retrieve all downstream versions with the archived version as the parent version, and redirect the parent version references of all downstream versions to the retained version.

[0018] By adopting the above technical solution, intelligent simplification and structural optimization of the version tree are achieved. The system can automatically identify sibling versions with highly similar content and competing relationships. By quantitatively comparing their content similarity and comprehensive recommendation scores, it intelligently selects to retain high-quality versions while archiving low-quality versions. This mechanism not only directly eliminates content redundancy and frees up storage space, but more importantly, it maintains the clarity of the version tree structure. By automatically redirecting downstream versions of archived versions back to retained versions, the system simplifies the version history while fully maintaining the continuity of the evolution path and the validity of reference relationships. This ensures the complete traceability of the version evolution history and effectively solves the problem of chaotic version tree structures and unclear main lines caused by version proliferation.

[0019] A second aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing.

[0020] A third aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions.

[0021] A fourth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method as described in any of the preceding claims.

[0022] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: By introducing composite version serial numbers to construct a clear evolution path, and combining global, path, and local three-layer quantity control to suppress version redundancy from the source, storage resources are optimized using layered storage and automatic cleanup mechanisms, and key history is fully preserved through intelligent version solidification. Furthermore, a multi-dimensional quality assessment system integrating semantic analysis, reference relationships, AI detection, and manual review is used to objectively quantify version value, and a version merging function based on similarity judgment is used to continuously optimize the version tree structure. Finally, a weighted scoring model is used to automatically recommend high-quality final versions, thus systematically solving the technical defects of traditional version management, such as chaotic version lineage, excessive redundancy, low screening efficiency, and strong subjectivity, and realizing a leap from passive recording to proactive intelligent management. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the system architecture of an embodiment of a document version evolution relationship analysis method based on data lineage according to this application; Figure 2 This is a flowchart illustrating a document version evolution relationship analysis method based on data lineage disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0024] Explanation of reference numerals in the attached figures: 100, System architecture; 101, First terminal device; 102, Second terminal device; 103, Third terminal device; 104, Network; 105, Server; 301, Processor; 302, Communication bus; 303, User interface; 304, Network interface; 305, Memory. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0026] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0027] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] Figure 1 This is a schematic diagram of the system architecture of an embodiment of a document version evolution relationship analysis method based on data lineage according to this application.

[0029] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0030] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0031] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP3 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0032] This embodiment discloses a document version evolution relationship analysis method based on data lineage. Figure 2 This is a flowchart illustrating a document version evolution relationship analysis method based on data lineage disclosed in an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps: S201. Receive a version creation request for a preset document library, wherein the version creation request is used to specify a parent version; Specifically, it listens for and receives version creation requests from one or more terminal devices. One concrete implementation involves sending a request following a concrete state transfer style via the HTTP (Hypertext Transfer Protocol) POST method. The target URI (Uniform Resource Identifier) ​​can be designed to identify a specific document repository, such as / api / projects / {project_id} / docs / {doc_id} / versions. The request body is typically in JSON (JavaScript Object Notation) format, encapsulating the core data needed to create a new version. This includes a `content` field containing the new document content and a crucial `parent_version_id` field specifying its evolution source; the value of this field is a unique identifier of the parent version to be inherited. Alternatively, for a more automated approach, the request can be triggered by the client's autosave mechanism. For example, when the client detects a change in document content and a preset time interval (e.g., 30 seconds) has elapsed, it automatically constructs and sends this request, achieving seamless version recording. It's worth noting that, to support the creation of entirely new documents, the system handles the `parent_version_id` field flexibly: when the value of this field in the request is null, an empty string, or the field is not provided, the system interprets it as creating a "root version" without a parent version. This root version will serve as the starting point for all subsequent version evolutions. After successfully receiving and verifying the validity of the request, the electronic device will parse out the parent version identifier, content data, and possibly other metadata (such as author, timestamp, commit message, etc.), preparing for subsequent steps of data lineage construction and analysis.

[0033] S202. Based on the parent version, determine the potential evolution path of the version to be created, and perform a multi-dimensional quantity control check based on the potential evolution path; One approach is to directly extract the identifiers of all upstream versions from the root version to the parent version by parsing its own composite version sequence number, thus instantly constructing a complete historical path. Another option is to start from a specified parent version ID and recursively query upwards through the database until the root version is found. Based on this determined potential evolutionary path (i.e., the historical path plus the new node to be created), the system will perform a multi-dimensional quantity control check against a set of pre-configurable thresholds. For example, this check may include: First, at the global level, querying the database to count the total number of versions in the entire document library, ensuring it does not exceed a full-tree threshold (e.g., 500); Second, at the path level, calculating the depth of the potential evolutionary path, ensuring it does not exceed a single-chain threshold (e.g., 50) to suppress excessively long revision chains; Third, at the local stage level, identifying and counting the number of minor change versions (e.g., drafts) between two adjacent key evolutionary stages (e.g., AI-generated draft and human-revised draft), ensuring it does not exceed a stage threshold (e.g., 10) to prevent excessive redundant intermediate states from being generated at the same stage. The version creation process will only continue if all dimensions of the check pass; otherwise, the creation will be aborted and the user will be returned with the corresponding prompt message.

[0034] Optionally, the step of determining the potential evolution path of the version to be created based on the parent version, and performing a multi-dimensional quantity control check based on the potential evolution path, includes: counting the number of first versions of all versions in the document library; if the number of first versions exceeds a preset full-tree threshold, the multi-dimensional quantity control check is deemed to have failed; counting the number of second versions of all versions in the potential evolution path; if the number of second versions exceeds a preset single-chain threshold, the multi-dimensional quantity control check is deemed to have failed; identifying adjacent evolutionary stages in the potential evolution path, and counting the number of third versions of all versions between the adjacent evolutionary stages; if the number of third versions exceeds a preset stage threshold, the multi-dimensional quantity control check is deemed to have failed.

[0035] As a specific implementation of multi-dimensional quantity control checks, this method can include controlling the total number of versions in the document repository. Specifically, when performing this check, the electronic device first counts the number of first versions of all existing versions in the document repository, i.e., the total number of versions. One technical implementation is that the electronic device initiates a query request to the database system it is connected to, for example, executing a SQL-like (Structured Query Language) command: `SELECT COUNT(id) FROM versions WHERE document_id=?`, where `document_id` is the unique identifier of the document repository currently being operated on. The count value returned by the database is the total number of versions. As a performance optimization option, this total number of versions does not need to be queried in real time every time, but can be cached or stored as a metadata field (e.g., `version_count`) along with the document repository object. After each successful creation or deletion of a version, the count field is incremented or decremented through atomic operations. Then, the system compares the obtained total number of versions with a preset full-tree threshold. This full-tree threshold is a global upper limit configured by the system administrator or user based on storage resources, management costs, and performance expectations, for example, it can be set to 500 or 1000. If the total number of versions plus the version to be created exceeds the preset full-tree threshold, the system determines that the multi-dimensional quantity control check has failed and can stop the version creation process, returning the corresponding prompt information to the user, such as the total number of versions has reached the limit.

[0036] Furthermore, to avoid the version history becoming difficult to trace and understand due to an excessively long single evolutionary branch, the method may also include control over the depth of the evolutionary path. In this step, the electronic device counts the number of second versions in all versions of the potential evolutionary path, i.e., the depth of the evolutionary path. The aforementioned step S202 has determined the complete path from the root version to the parent version of the version to be created. This path can typically be represented as an ordered list or array containing unique identifiers for each version. One direct implementation is that the system directly calculates the length of this ordered list and then adds 1 (representing the new version to be created) to obtain the total depth of the potential evolutionary path. Another implementation is that if the system uses composite version sequence numbers (e.g., 1.2.5) to encode the parent-child relationship between versions, the path depth of the new version can be quickly obtained by parsing the sequence number of the parent version of the version to be created (e.g., the depth of 1.2.5 is 3) and adding 1 to its depth value. The system compares the calculated path depth with a preset single-chain threshold. This single-chain threshold is designed to limit the length of a single, continuous revision chain and can be configured according to business needs, for example, set to 50 or 100. If the calculated path depth exceeds the threshold, the multi-dimensional quantity control check is deemed to have failed, thereby encouraging users to perform version integration or create new major branches when appropriate, rather than making endless linear revisions.

[0037] Furthermore, to improve the clarity of version history between key nodes and avoid a large number of trivial intermediate versions between two meaningful evolutionary stages, the method can also include control over the number of staged versions. First, the system needs to be able to identify adjacent evolutionary stages in the potential evolutionary path. This is typically achieved by introducing type or tag metadata for versions. One specific implementation is to assign a type to a version when it is created, such as AI-generated draft, manually revised draft, key milestone, or automatically saved draft. AI-generated drafts and key milestones can be defined as markers of evolutionary stages. During the check, the system starts from the parent version of the version to be created and backtracks along the potential evolutionary path towards the root version until it finds the first ancestor version marked as an evolutionary stage. Then, the system counts the number of all versions between this ancestor version and the parent version; this number is the third version count. As an alternative, the system can also dynamically identify evolutionary stages by analyzing whether the version's commit message contains specific keywords (such as [milestone], [release]). After the count is completed, the system compares this number with a preset stage threshold (e.g., 5 or 10). If the number exceeds the threshold, it is considered that there are too many redundant revisions between the two key stages, and the multi-dimensional quantity control check is deemed to have failed, thus ensuring that the main thread of the version history is clearly identifiable.

[0038] In a preferred embodiment, when the version type field is not explicitly specified by the user, the system can also determine the evolution stage through the following automatic identification rules: First, the system extracts metadata at the time of version creation, including but not limited to content difference, manual review status, and number of downstream references. When one of the following conditions is met, the version is automatically marked as an evolution stage node: (1) the content difference is greater than a preset threshold (e.g., 0.5, i.e., more than 50% substantial modification relative to the parent version); (2) the manual review status is passed; (3) the number of downstream references is greater than a preset threshold (e.g., 3 or more sub-versions). After determining all evolution stage nodes in the path, the system sorts them in chronological order, starting from the parent version of the version to be created and tracing back towards the root version to locate the first ancestor version marked as an evolution stage. If no evolution stage node is found after tracing back to the root version, the root version is regarded as the initial evolution stage by default. All versions between the ancestor version and the parent version are the statistical objects, and their number is the number of the third version.

[0039] S203. When the multi-dimensional quantity control check passes, the version to be created is created, and a composite version serial number is generated for the version to be created. The composite version serial number encodes the complete evolution path from the root version to the version to be created. The root version refers to a version that does not have a parent version. Specifically, the version creation process technically refers to inserting a new record into the version table of the database. This record contains at least a globally unique identifier generated by the system, document content, an identifier pointing to its parent version, and metadata such as creation time. The core of this step lies in the logic for generating the composite version serial number, which aims to directly encode the genealogical relationship of the versions into the serial number itself. One specific implementation is as follows: The system first checks if the parent version exists. If it does not exist, it indicates that the currently created version is the root version (i.e., a version without a parent version), and the system assigns it an initial serial number, such as the number 1. If the parent version exists, the system first obtains the composite version serial number of the parent version, such as a sequence like 1.2, and then queries the database to count the number of direct child versions that the parent version currently has. Assuming the count result is 2, the new version's serial number will be based on the parent version's serial number, using a preset separator (such as a period) to connect a new number obtained by adding 1 to the count value (i.e., 3), thus generating a new composite version serial number 1.2.3. As an optional and more performant implementation, to avoid database queries on every occasion, a child version counter field can be directly maintained in the parent version record. Each time a child version is created, the system can atomically increment this counter and directly use the incremented value as the last segment of the new version sequence number, thus eliminating the query step. Through this mechanism, each generated composite version sequence number, such as 1.3.2.5, clearly encodes the complete evolutionary path from the root version to the current version. This allows for the immediate reconstruction of its complete lineage structure simply by parsing the sequence number string, greatly simplifying and accelerating any operation that requires tracing, comparing, or visualizing version history without performing resource-intensive recursive database queries.

[0040] To avoid duplicate composite version serial numbers generated due to multiple creation requests executing simultaneously in high-concurrency scenarios, the increment operation of the child version counter field should be implemented using atomic operations at the database level. One specific implementation is to use an atomic update statement like `UPDATE versions SET child_count = child_count + 1 WHERE id = parent_id RETURNING child_count` in a relational database. This statement locks the row during execution, ensuring that only one transaction can successfully increment and retrieve the new value at any given time, thus guaranteeing the uniqueness of the serial number. Another implementation is to use a distributed lock service (such as the `INCR` command based on Redis or distributed locks from ZooKeeper) to coordinate concurrent requests. Locks are applied during the two operations of retrieving the child version counter value from the parent version and updating that counter value, ensuring the atomicity of the operations.

[0041] S204. Configure a hierarchical storage status for the version to be created, obtain the target document version, and determine the quality evaluation index associated with the target document version based on the composite version serial number. Specifically, optionally, configuring a hierarchical storage state for the version to be created to obtain the target document version includes: adding the hierarchical storage state to the data structure of the version to be created, and setting the initial value of the hierarchical storage state attribute to a temporary storage state; configuring an associated timed cleanup rule for the version to be created based on the temporary storage state, wherein the timed cleanup rule cleans up document versions that are in the temporary storage state and have exceeded a preset duration; and using the version to be created with the added hierarchical storage state and the configured timed cleanup rule as the target document version.

[0042] In a preferred embodiment of this application, the step of configuring a hierarchical save status for a version to be created can specifically begin by modifying the version's data structure. The system adds an attribute field representing the hierarchical save status to the database table structure definition used to store version information, or to the object model (e.g., a class or structure) within its corresponding program code. This attribute field can be named, for example, `save_state` or `lifecycle_status`. When a version to be created is generated and instantiated by the system, the `save_state` attribute of that version is automatically assigned an initial value, which explicitly represents a temporary save status. The specific form of this initial value can be varied; for example, it can be a predefined integer value of 0, a descriptive string `TEMP`, or a member of the enumeration type `VersionState.TEMPORARY`. Through this operation, each newly generated version is logically temporarily categorized as an informal, pending state, providing the necessary preconditions for subsequent automated lifecycle management.

[0043] Furthermore, based on the temporary save status set in the previous step, the system configures associated scheduled cleanup rules for these temporary versions. This configuration does not involve generating a separate cleanup command for each temporary version, but rather incorporating them into a unified, system-level automated cleanup mechanism. One specific implementation is that the system runs a scheduled cleanup service in the background, which can be configured to be periodically activated at a preset time interval (e.g., hourly, every 24 hours, or weekly). Once activated, this service performs a database query, searching for all document versions with the `save_state` attribute value set to temporary save status. For each retrieved temporary version, the service reads its creation timestamp and calculates the elapsed time since its creation. If this elapsed time exceeds a preset duration threshold (which can be flexibly configured according to business needs, such as 48 hours), the version is deemed expired, and the cleanup service triggers a deletion operation, completely removing its version record and any associated storage files (such as difference data or full content) from the storage system.

[0044] Furthermore, the version to be created that has undergone the above two steps is taken as the target document version in this embodiment. In other words, this target document version is an entity that, based on the original version to be created, has added a hierarchical storage status attribute (with an initial value of temporary storage) to identify its lifecycle state, and is simultaneously placed under an automated management framework composed of periodic cleanup rules. This type of target document version, from its inception, possesses clear lifecycle management attributes, effectively preventing the accumulation of a large amount of useless, temporary version data due to frequent user editing, thereby ensuring the long-term stability and storage efficiency of the entire document version management system.

[0045] Optionally, the method further includes: receiving a setting instruction, the setting instruction specifying a version to be solidified, the version to be solidified being one or more of the target document versions stored in the document library; changing the hierarchical storage status of the version to be solidified to a manual permanent storage status, and clearing the timed cleanup rules associated with the version to be solidified; obtaining a specific complete evolution path of the version to be solidified by parsing the composite version serial number of the version to be solidified, and setting the hierarchical storage status of all upstream versions included in the specific complete evolution path to an automatic permanent storage status and clearing the timed cleanup rules associated with all upstream versions.

[0046] In some specific embodiments of this application, the method further provides a version persistence mechanism. This mechanism is triggered when the system receives a setting command for a specified version. The user can issue this command through a graphical interface, for example, by selecting a target document version from the version history list and activating a function to set it as a milestone or permanently save it. The command contains unique identification information for the version to be persisted, such as its primary key in the database or its composite version serial number. Upon receiving the command, the system locates the corresponding version record in storage based on this identification information and modifies its hierarchical storage status attribute, updating it from a value representing a temporary storage status to a new value representing a manually permanent storage status. This status change makes the version no longer meet the filtering conditions of the background scheduled cleanup task, effectively decoupling it from the scheduled cleanup rules and ensuring that this user-specified key version is permanently retained.

[0047] Furthermore, after the version to be solidified is set to be permanently stored, to ensure the recoverability of its content and the integrity of its historical dependencies, the system will perform an upward tracing parsing process. This process reconstructs its complete specific evolutionary path by analyzing the composite version sequence number of the version to be solidified. One specific implementation method is that the system derives its parent version number level by level from the current version number according to a preset sequence number decrementing rule, until the root version. For example, a version number of 3.1.2 can be deduced to have a parent version of 3.1. A more robust implementation method is that each version's data structure already contains an identifier pointing to its direct parent version. The system uses this identifier to perform a chained backtracking query until it finds an initial version without a parent version. Ultimately, the system will obtain an ordered set of all upstream versions, including the direct parent versions from the root version to the version to be solidified.

[0048] Furthermore, after successfully acquiring the evolution path containing all upstream versions, the system performs a state update operation on each upstream version in that path. Specifically, the system iterates through this set of upstream versions and sets the hierarchical storage state attribute value of each version to an automatically permanent storage state. This state is functionally equivalent to a manually permanent storage state, both of which prevent automatic cleanup, but semantically they are different, indicating that its solidification is automatically triggered by the system due to dependencies. This series of operations also clears all timed cleanup rules associated with upstream versions. The fundamental technical effect of this approach is to ensure data integrity, especially suitable for version control systems using incremental or differential storage. By solidifying the entire evolution path, it ensures that any milestone version marked by the user depends on a complete and immutable historical data chain, allowing for accurate and timely recovery and review.

[0049] Optionally, determining the quality assessment indicators associated with the target document version based on the composite version serial number includes: obtaining the AI ​​detection rate and manual review status of the target document version; calculating the content difference degree based on the content data of the target document version and the content data of the parent version of the target document version, and determining the intensity of manual modification based on the content difference degree; analyzing the content data of the target document version to obtain content structure parameters, and determining the content completeness and standardization based on the content structure parameters through a preset multi-indicator weighting rule; and determining the depth of the complete evolution path and the sibling version of the sibling version with the same parent version as the target document version based on the composite version serial number. The quantity is calculated, and based on the depth and the number of sibling versions, the link simplicity is obtained through a preset complexity calculation formula; the number of all documents in the document library with the target document version as the parent version is counted, and the number is determined as the number of downstream version citations, and the citation importance is determined based on the number of downstream version citations; the time difference is calculated based on the creation time of the target document version and the current system time, and the time freshness is determined based on the time difference and a preset function; the quality evaluation index is obtained by combining the AI ​​detection rate, the manual review status, the manual modification intensity, the content completeness and standardization, the link simplicity, the citation importance, and the time freshness.

[0050] Specifically, the system obtains the AI ​​detection rate and human review status of the target document version and converts them into corresponding quantitative scores. To determine the AI ​​detection rate score (also known as the human similarity score), the system calls the AI ​​content detection service to obtain an aiRate value representing the probability that the content was generated by AI. The formula for calculating this score is: Human Similarity Score = 1 - aiRate. For example, if the detection service returns an aiRate of 0.1 (i.e., a 10% probability of AI generation), then the score for this dimension is 0.9. This score intuitively reflects the originality of the content and its similarity to human writing style; a higher score indicates that the content is more likely to have been created by a human. At the same time, the system maps the discrete "human review status" to a review endorsement score. A specific mapping rule is: a status of "approved" is mapped to a full score of 1.0; a status of "submitted for review" is mapped to 0.8; a status of "draft not submitted" is mapped to 0.6; and a status of "rejected" is mapped to a lower score of 0.2.

[0051] Furthermore, to determine the intensity score of manual modifications, the system aims to quantify the degree of meaningful change in the target version compared to its parent version and encourages "moderate and effective" modifications. One specific implementation involves calculating the content difference value diff (e.g., diff = 1 - cosine similarity) and then using a Gaussian function (i.e., a normal distribution function) to calculate the score, with the formula: Manual Modification Intensity Score = exp(-(diff - optimal)) 2 ) / (2×sigma 2 In this formula, `optimal` is the preset optimal difference level, for example, 0.3, meaning that a modification of around 30% is considered the most valuable; `sigma` is the standard deviation, which controls the "width" of the score curve, for example, it can be set to 0.15, meaning that a higher score can be obtained within a certain range of the difference level near `optimal`. When `diff` is exactly equal to `optimal`, the score is exp(0), which is 1.0 (full score); the further `diff` deviates from `optimal`, the faster the score drops exponentially. As a lower computational cost option, the system can use a piecewise linear function, for example, setting the score to 1.0 within the interval `diff` of [0.2, 0.4], and linearly decreasing to 0 outside this interval.

[0052] Secondly, the system assesses the structural quality of a document by determining a content completeness and standardization score. The processor parses the document content and extracts multiple predefined content structure parameters, calculating a sub-score for each parameter independently. For example: 1) Word count: A target range [min_words, max_words] is set. If the document's word count falls within this range, the word count sub-score is 1.0; if it exceeds the range, points are deducted linearly based on the excess percentage. 2) Heading hierarchy: The system checks whether the document contains a complete heading hierarchy from H1 to Hn. For each missing necessary heading level, the heading sub-score is reduced by 0.2 points. 3) Keyword density: The system calculates the frequency of core keywords. If the density is within the ideal range (e.g., 1.5% to 3%), the density sub-score is 1.0. Finally, the content completeness and standardization score is obtained by weighted summation of all sub-scores: Total score = w1 × word count sub-score + w2 × heading sub-score + w3 × density sub-score + ..., where the weights w1, w2, w3... can be preset according to business needs, and the sum is 1.

[0053] Furthermore, the system evaluates the clarity of the evolution path of a version in the data lineage tree by calculating a link simplicity score. This score is the inverse vector degree of the version link complexity. The system determines its depth (depth=4) by parsing the version composite sequence number (e.g., 1.3.2.5) and determines the number of its sibling versions (branchCount) by querying the database. This score can be calculated by a preset formula, for example: Link Simplicity Score = max(0.2, 1.0 - 0.1 × (branchCount - 1)) × (1.0 / (1.0 + 0.05 × (depth - 1))). The logic of this formula is: the base score is 1.0, and for each additional sibling version (i.e., a branch is generated), the score is reduced by 0.1, but not lower than 0.2; at the same time, the deeper the path, the larger the denominator, and the lower the score accordingly. This mechanism encourages users to maintain a clear and linear version evolution. As a simpler alternative implementation, a more direct reciprocal relationship can be used, for example, score = 1.0 / (depth + branchCount).

[0054] Furthermore, the system measures a version's influence in subsequent workflows by determining a citation importance score. This score is based on the number of downstream version citations (citationCount), i.e., the total number of child versions created with the current target version as the parent version. To reflect the principle of diminishing marginal returns, the system uses an exponential saturation function for calculation: Citation Importance Score = 1.0 - exp(-λ × citationCount). Here, λ is a configurable coefficient (e.g., 0.2) used to control the rate at which the score approaches 1.0. When a version has no child versions (citationCount = 0), its score is 0; as the number of child versions increases, the score rises rapidly, but the growth rate gradually slows down, eventually approaching 1.0. This ensures that even versions with extremely high citation counts do not have a disproportionate weight in the total score.

[0055] Furthermore, to reflect the timeliness of the version, the system calculates a freshness score. The processor obtains the creation timestamp of the target document version and subtracts it from the current system time to obtain a time difference value (daysOld) in days. The score is quantified using an exponential decay function: Freshness Score = exp(-μ × daysOld). Here, μ is a coefficient controlling the decay rate (e.g., 0.02), and its value determines the score's "half-life" (i.e., the time required for the score to decay to 50%). For example, when μ = 0.02, the score will decay to about 50% of its initial value after approximately 35 days. This ensures that, given comparable quality dimensions, more recently created versions receive a higher recommendation priority.

[0056] Furthermore, the system combines the standardized scores of the seven dimensions calculated in the preceding steps into a structured dataset, which constitutes the complete quality assessment metric associated with the target document version. One specific implementation is that the system generates a JSON object for each target version, where the key is a clear identifier for each assessment dimension, and the value is its corresponding quantified score in the [0, 1] interval. As a performance-optimized alternative, this metric can also be a fixed-order array of values ​​(e.g., [0.95, 1.0, 0.88, 0.92, 0.75, 0.63, 0.98]) to reduce storage and transmission overhead.

[0057] Optionally, calculating the content difference based on the content data of the target document version and the content data of the parent version of the target document version includes: converting the content data of the target document version and the content data of the parent version of the target document version into a target content vector and a parent content vector respectively using a preset text vectorization model; calculating the cosine similarity between the target content vector and the parent content vector to obtain a similarity value; and determining the content difference based on the similarity value using a preset difference conversion function.

[0058] In one specific implementation, to calculate content dissimilarity, the system first processes the content data of the target document version and its parent version separately using a pre-defined text vectorization model. This process converts unstructured text content into high-dimensional numerical vectors capable of mathematical operations. This pre-defined text vectorization model can be of several types. For example, one implementation uses a pre-trained language model based on deep learning, such as BERT, RoBERTa, or Sentence-Transformers. In this approach, the system takes the entire document or its core paragraphs as input, feeds them into the model, and takes a specific output layer (e.g., the vector corresponding to the [CLS] tag or the average pooling result of all word vectors) as a dense vector representing the document's semantics. Another optional implementation uses traditional text representation methods, such as the TF-IDF (Term Frequency-Inverse Document Frequency) model, which generates a sparse vector reflecting the keyword distribution for each document. The choice of model can be configured at the system level to balance computational efficiency and semantic accuracy.

[0059] Furthermore, after successfully converting the content of the target document version and its parent version into target content vectors and parent content vectors respectively, the system calculates the cosine similarity between these two vectors. Cosine similarity is a metric that measures the directional difference between two vectors, and its result is a value between -1 and 1. In text processing, when using non-negative vector representations (such as TF-IDF) or specially processed semantic vectors, this value is typically between 0 and 1. A value of 1 indicates that the two vectors point in exactly the same direction, corresponding to semantically identical document content; a value of 0 indicates that the two vectors are orthogonal, corresponding to semantically unrelated document content. This calculation follows a standard linear algebra formula: the dot product of the two vectors divided by the product of their respective magnitudes. This calculation process can be efficiently performed by general-purpose mathematical libraries, resulting in a similarity value that quantifies the degree of similarity between the two versions of content.

[0060] Furthermore, the system uses the similarity score obtained in the previous step and a preset difference conversion function to determine the final content difference score. The purpose of this conversion function is to transform the similarity metric into a more intuitive measure of difference. One of the simplest and most direct implementations is to use a linear inversion function; for example, the content difference score equals 1 minus the similarity score. Under this function, if the similarity score is 1, the content difference score is 0, indicating no change; if the similarity score is 0, the content difference score is 1, indicating completely different content. In other embodiments, the conversion function can also be a configurable non-linear function, for example, multiplied by a constant (such as 100) to convert it to a percentage, or using exponential or logarithmic functions to amplify or reduce the sensitivity of a specific similarity interval to meet specific business analysis needs. Through this step, the system ultimately obtains a standardized and easily understood content difference score, providing support for subsequent quality assessment and version management.

[0061] Optionally, the method further includes: selecting multiple sibling versions with the same parent version in the document library as candidate versions to be merged; calculating the content similarity between any two versions among the candidate versions to be merged, and if the content similarity is higher than a preset merging threshold, determining the version with the higher overall recommendation score among the two versions as the retained version, and determining the version with the lower overall recommendation score among the two versions as the archived version; updating the status identifier of the archived version to the merged status, releasing the storage space occupied by the archived version, and retrieving all downstream versions with the archived version as the parent version, and redirecting the parent version reference relationship of all downstream versions to the retained version.

[0062] In some preferred embodiments, to further optimize the version structure of the document repository and reduce redundant storage, the technical solution provided in this application may also include an automated version branch merging and archiving process. The first step of this process is to filter out multiple sibling versions in the document repository that share the same parent version as candidate versions to be merged. Specifically, the system can perform this operation through a database query. For example, by using a specific parent version ID, it can retrieve all records in the version table whose `parent_version_id` field matches that ID; the versions corresponding to these records constitute a set of sibling versions. The triggering mechanism for this filtering process can be varied: one approach is for the system administrator to manually select a parent version and initiate a merge check in the management backend; another approach is for the system to configure a periodic task (e.g., a batch job executed every morning) to automatically scan document branches that have had new versions generated in the past 24 hours. To improve efficiency, additional filtering conditions can be added during the filtering process, such as only including versions that have not yet been marked as milestones or are in a draft state in the candidate version set to be merged, thereby avoiding accidental operations on important stable versions.

[0063] Furthermore, after determining the set of candidate versions to be merged, the system will perform a comparison and decision-making step, namely, calculating the content similarity between any two versions in the candidate versions to be merged, and if the content similarity is higher than a preset merging threshold, the version with the higher overall recommendation score is determined as the retained version, and the version with the lower overall recommendation score is determined as the archived version. In this step, the system will traverse all version pairs in the candidate version set. For each pair of versions, the system calls the aforementioned content similarity calculation module, for example, through text vectorization and cosine similarity algorithm, to obtain a numerical value quantifying its content overlap. The key is that the system will compare this similarity value with a preset merging threshold (e.g., configurable to 0.98 or a higher value). Only when the similarity is higher than this threshold does the system consider the two versions to be highly overlapping in content, redundant, and need to be merged. This usually corresponds to minor modifications by the same author or nearly identical edits by different authors. Once this condition is met, the system will obtain the calculated overall recommendation scores for the two versions separately, and determine the version with the higher score as the retained version and the version with the lower score as the archived version. The overall recommendation score here serves as a comprehensive quality indicator, ensuring that when merging similar content, the version with higher quality and greater potential is retained.

[0064] Further, the system will perform specific archiving and version chain reconstruction operations. This step includes: updating the status identifier of the archived version to "merged," releasing the storage space occupied by the archived version, and retrieving all downstream versions with the archived version as the parent version, and redirecting the parent version references of all downstream versions to the retained version. First, the system updates the status field of the archived version in the database to "merged" or "archived," making it hidden or specially marked in the regular version history view. Next, the system performs storage space release. One implementation is to mark the content files or database records associated with the archived version as deletable and physically delete them using a background garbage collection mechanism. A more robust alternative is to migrate the data of the archived version to lower-cost cold storage (such as the archiving layer of object storage) and retain it for a fixed period of time (such as 30 days) before permanent deletion, for auditing or rollback purposes. A crucial step is maintaining the integrity of the version evolution tree: the system retrieves all downstream versions with the archived version ID as the parent version and batch updates the parent version references of these downstream version records to point to the ID of the currently determined retained version. This series of atomic operations ensures that while the version branch is simplified, all historical dependency chains of subsequent work are continued completely and correctly, thereby achieving a slimmer and more optimized document library without losing any valid evolution path.

[0065] S205. Calculate the comprehensive recommendation score of the target document version based on the quality assessment indicators and the preset weighted model; In a preferred embodiment of this application, the preset weighted model is a linear weighted summation model. Under this model, the system pre-configures a weight coefficient for each of the seven evaluation dimensions. These weight coefficients are set by the system administrator according to business needs (e.g., whether originality or content standardization is more important), representing the importance of each dimension in the final comprehensive evaluation. The sum of all weight coefficients is preferably set to one to ensure the normalization of the final score. For example, the weight of "AI detection rate score" can be set to 0.35, "human review status score" to 0.15, "human modification intensity score" to 0.15, "content completeness and standardization score" to 0.1, "link simplicity score" to 0.1, "citation importance score" to 0.1, and "time freshness score" to 0.05. During calculation, the processor multiplies the score value of each dimension with its corresponding preset weight coefficient, and then adds all the products calculated for these seven dimensions. The sum obtained is the comprehensive recommendation score for the target document version. The advantages of this method are that its calculation logic is clear, its implementation is simple, and its weight configuration is flexible, making it easy to make quick adjustments according to changes in business strategies.

[0066] In another optional, more advanced embodiment, the pre-defined weighted model can also be a trained machine learning model, such as a gradient boosting decision tree model or a miniaturized neural network model. In this implementation, the system first needs to prepare a training dataset containing a large number of historical document versions as samples. In this dataset, the input features of each sample are the quality assessment scores of the seven dimensions calculated in the preceding steps, while its training label can be an objective indicator reflecting the final value of the version, such as whether the version was ultimately adopted as the "official version," its subsequent positive user feedback rating, or its long-term influence index within the entire content ecosystem. Through supervised learning training on such a dataset, the machine learning model can automatically learn the complex, non-linear intrinsic relationship between each quality dimension and the final success probability of the version. When actually evaluating a new version, the system passes the version's seven-dimensional scores as input to this trained model, and the model's output prediction (e.g., a value representing the probability of "high quality") can be directly used as its comprehensive recommendation score. This adaptive scoring method can more accurately fit real-world business scenarios and, through regular model iteration and retraining, continuously adapt to the evolution of content standards and user preferences, achieving higher-precision version quality assessment. Regardless of the weighted model used, this step provides crucial quantitative evidence for the subsequent automated and efficient selection of the best version from a massive pool of versions.

[0067] S206. Based on the comprehensive recommendation score, determine the final version from the multiple target document versions stored in the document library.

[0068] One direct and efficient implementation is for the system to sort all target document versions within a specified range (e.g., all active branch versions of the same document) in descending order of their overall recommendation score and automatically select the version with the highest score as the final version. A more robust alternative implementation is for the system to first compare the overall recommendation score of all versions with a preset "final version adoption threshold." Only versions with scores higher than this threshold are included in the candidate set, and the system then selects the version with the highest score from this candidate set as the final version. If no version's score exceeds the threshold, the system can decide not to use any final version and trigger an alert or notification requiring manual intervention. This determined "final version" can then be used by the system for various purposes; for example, its status can be marked as "officially recommended" to be displayed as the default version when a user visits the document, or it can serve as the parent version for subsequent content creation.

[0069] This embodiment also discloses an electronic device, as shown in the reference. Figure 3The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0070] The communication bus 302 is used to enable communication between these components.

[0071] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0072] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0073] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0074] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory 305 may include non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program based on a document version evolution relationship analysis method based on data lineage.

[0075] exist Figure 3 In the electronic device shown, the user interface 303 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 301 can be used to call an application program stored in the memory 305 that is a document version evolution relationship analysis method based on data lineage. When executed by one or more processors 301, the electronic device executes one or more methods as described in the above embodiments.

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

[0077] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0078] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0079] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0080] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A document version evolution relationship analysis method based on data lineage, characterized in that, Applied to a server, the method includes: Receive a version creation request for a preset document library, wherein the version creation request is used to specify a parent version; Based on the parent version, determine the potential evolution path of the version to be created, and perform multi-dimensional quantity control checks based on the potential evolution path; When the multi-dimensional quantity control check passes, the version to be created is created, and a composite version serial number is generated for the version to be created. The composite version serial number encodes the complete evolution path from the root version to the version to be created. The root version refers to a version that does not have a parent version. Configure a hierarchical storage status for the version to be created, obtain the target document version, and determine the quality assessment index associated with the target document version based on the composite version serial number; Based on the quality assessment indicators and the preset weighted model, calculate the comprehensive recommendation score for the target document version; Based on the comprehensive recommendation score, the final version is determined from multiple target document versions stored in the document library.

2. The method according to claim 1, characterized in that, The step of determining the potential evolution path of the version to be created based on the parent version, and performing multi-dimensional quantity control checks based on the potential evolution path, includes: The number of first versions in all versions of the document library is counted. If the number of first versions exceeds the preset full tree threshold, the multi-dimensional quantity control check is deemed to have failed. The number of second versions in all versions of the potential evolutionary path is counted. If the number of second versions exceeds a preset single-chain threshold, the multi-dimensional quantity control check is deemed to have failed. Identify adjacent evolutionary stages in the potential evolutionary path and count the number of third versions of all versions between the adjacent evolutionary stages. If the number of third versions exceeds a preset stage threshold, the multi-dimensional quantity control check is deemed to have failed.

3. The method according to claim 1, characterized in that, The step of configuring a hierarchical storage status for the version to be created, to obtain the target document version, includes: Add the hierarchical storage state to the data structure of the version to be created, and set the initial value of the hierarchical storage state attribute to temporary storage state; Based on the temporary storage state, a timed cleanup rule is configured for the version to be created. The timed cleanup rule cleans up document versions that are in the temporary storage state and have exceeded the preset storage duration. The version to be created, which has been given the layered storage status and configured with the timed cleanup rules, will be used as the target document version.

4. The method according to claim 3, characterized in that, The method further includes: Receive a setting instruction, which specifies the version to be solidified, wherein the version to be solidified is one or more of the target document versions stored in the document library; Change the layered save status of the version to be solidified to manual permanent save status, and clear the timed cleanup rules associated with the version to be solidified; The specific complete evolution path of the version to be solidified is obtained by parsing the composite version serial number of the version to be solidified, and the hierarchical storage status of all upstream versions contained in the specific complete evolution path is set to automatic permanent storage status and the timed cleanup rules associated with all upstream versions are cleared.

5. The method according to claim 1, characterized in that, The step of determining the quality assessment metrics associated with the target document version based on the composite version serial number includes: Obtain the AI ​​detection rate and manual review status of the target document version; Based on the content data of the target document version and the content data of the parent version of the target document version, calculate the content difference degree, and determine the intensity of manual modification based on the content difference degree; The content data of the target document version is analyzed to obtain content structure parameters, and the completeness and standardization of the content are determined based on the content structure parameters through a preset multi-indicator weighting rule. Based on the composite version sequence number, determine the depth of the complete evolution path and the number of sibling versions of sibling versions that have the same parent version as the target document version, and obtain the link simplicity based on the depth and the number of sibling versions through a preset complexity calculation formula. The number of all documents in the document library with the target document version as the parent version is counted, and the number is determined as the number of references in downstream versions. The importance of being referenced is determined based on the number of references in downstream versions. Calculate the time difference based on the creation time of the target document version and the current system time, and determine the time freshness based on the time difference and a preset function; The quality assessment index is obtained by combining the AI ​​detection rate, the status of manual review, the intensity of manual modification, the completeness and standardization of content, the simplicity of the link, the importance of citation, and the freshness of time.

6. The method according to claim 5, characterized in that, The step of calculating the content difference based on the content data of the target document version and the content data of the parent version of the target document version includes: Using a preset text vectorization model, the content data of the target document version and the content data of the parent version of the target document version are converted into target content vector and parent content vector, respectively. Calculate the cosine similarity between the target content vector and the parent content vector to obtain a similarity value; Based on the similarity value, the content difference is determined using a preset difference conversion function.

7. The method according to claim 5, characterized in that, The method further includes: Select multiple sibling versions with the same parent version from the document library as candidate versions to be merged. Calculate the content similarity between any two versions in the candidate versions to be merged, and if the content similarity is higher than a preset merging threshold, determine the version with the higher comprehensive recommendation score among the two versions as the retained version, and determine the version with the lower comprehensive recommendation score among the two versions as the archived version; Update the status identifier of the archived version to "merged", release the storage space occupied by the archived version, retrieve all downstream versions with the archived version as the parent version, and redirect the parent version references of all downstream versions to the retained version.

8. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-7.

Images