Document processing method, apparatus, device, and medium

Abstract

This invention relates to the field of software development technology and discloses a document processing method, apparatus, device, and medium. The method includes: acquiring multiple heterogeneous data sources of a software project, wherein the heterogeneous data sources include at least source code and software documents associated with the source code; constructing a semantic difference graph describing the semantic relationships between the heterogeneous data sources based on the multiple heterogeneous data sources; assessing the synchronization risk value between the software documents and the current source code based on the semantic difference graph; if the synchronization risk value exceeds a preset threshold, determining the target content in the software documents that needs to be updated synchronously based on the semantic difference graph; generating differential update information for updating the target content based on the current source code and the semantic difference graph; and triggering an update processing flow for the software documents based on the differential update information. This method can be applied to document processing scenarios in fintech and healthcare, improving the accuracy and efficiency of document processing.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a document processing method, apparatus, device, and medium. Background Technology

[0002] In software development within the fintech and healthcare sectors, especially among large enterprises (such as financial and internet groups) adopting agile development and microservice architectures, code iteration and deployment are extremely rapid. During this process, various project documents (such as compliance requirements documents and risk control model design documents for financial transaction systems, or HIPAA (Health Insurance Portability and Accountability Act) compliance interface documents and clinical decision support system API specifications in healthcare systems) serve as crucial knowledge carriers recording core business logic, regulatory requirements, and inter-system collaboration agreements. Their maintenance and updates heavily rely on manual intervention. After code changes, developers must manually search for and modify all relevant documents—a tedious and easily overlooked process that results in low accuracy and efficiency in document processing, leading to a widespread "document lag" problem between document content and code implementation.

[0003] In existing technologies, static documentation generation tools based on code comments (such as Swagger and Javadoc) can automatically generate API interface documentation based on specific comment tags, but their coverage is limited to surface information such as interface signatures, failing to encompass deeper semantics such as requirements, design logic, and business processes. Furthermore, these tools rely entirely on comment updates, representing a passive and lagging generation mode that cannot reflect substantial changes in code logic that have occurred but are not covered by comments, thus limiting the accuracy of documentation processing. On the other hand, static code inspection tools integrated into continuous integration / continuous deployment (CI / CD) processes (such as code style checks and complexity analysis) primarily focus on the quality metrics of the code itself, lacking the ability to understand business semantics. Therefore, they struggle to identify whether the code implementation deviates from the business intent described in the original requirements document, similarly impacting the accuracy of documentation processing. Summary of the Invention

[0004] This invention provides a document processing method, apparatus, device, and medium to solve the technical problem that existing document processing methods have low accuracy and efficiency.

[0005] Firstly, a document processing method is provided, including: Acquire multiple heterogeneous data sources for a software project, wherein the heterogeneous data sources include at least source code and software documentation associated with the source code; Construct a semantic difference map describing the semantic relationships between the multiple heterogeneous data sources; The synchronization risk value between the software document and the current source code is assessed based on the semantic difference graph. If the synchronization risk value exceeds a preset threshold, the target content in the software document that needs to be synchronized and updated is determined based on the semantic difference map. Based on the current source code and the semantic difference graph, differential update information is generated to update the target content, and the update process of the software document is triggered based on the differential update information.

[0006] Secondly, a document processing apparatus is provided, comprising: An acquisition unit is used to acquire multiple heterogeneous data sources of a software project, wherein the heterogeneous data sources include at least source code and software documents associated with the source code; The construction unit is used to construct a semantic difference map describing the semantic relationships between the heterogeneous data sources based on the multiple heterogeneous data sources; An evaluation unit is used to evaluate the synchronization risk value between the software document and the current source code based on the semantic difference graph; The determining unit is used to determine the target content in the software document that needs to be synchronously updated based on the semantic difference map if the synchronization risk value exceeds a preset threshold. A trigger generation unit is used to generate differential update information for updating the target content based on the current source code and the semantic difference graph, and to trigger the update process of the software document based on the differential update information.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described document processing method.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described document processing method.

[0009] The above-described document processing method, apparatus, computer equipment, and storage medium can acquire multiple heterogeneous data sources of a software project, wherein the heterogeneous data sources include at least source code and software documents associated with the source code; construct a semantic difference graph describing the semantic relationships between the heterogeneous data sources based on the multiple heterogeneous data sources; assess the synchronization risk value between the software document and the current source code based on the semantic difference graph; if the synchronization risk value exceeds a preset threshold, determine the target content in the software document that needs to be updated synchronously based on the semantic difference graph; generate differential update information for updating the target content based on the current source code and the semantic difference graph; and trigger the update processing flow of the software document based on the differential update information. In this invention, by automatically constructing a semantic difference graph connecting multiple heterogeneous data sources, continuous monitoring and quantitative evaluation of the synchronization status of software documents are achieved. When the evaluated synchronization risk value exceeds a preset threshold, the specific target content to be updated in the document is located, and differential update information is automatically generated based on the current source code, thereby triggering the update processing flow. This transforms the traditional manual, lagging, and error-prone document maintenance into precise, proactive, and automated closed-loop management, thereby improving the accuracy and efficiency of document processing. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a document processing method according to an embodiment of the present invention; Figure 2 yes Figure 1 A schematic diagram of a specific implementation of step S120; Figure 3 yes Figure 1 A schematic diagram of a specific implementation of step S130; Figure 4 yes Figure 1 A schematic diagram of a specific implementation of step S150; Figure 5 This is a schematic block diagram of a document processing device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 7 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] The document processing method provided in this invention can be applied to either a client or a server. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. Currently, in the fintech and healthcare fields, the accuracy and efficiency of existing document processing methods are relatively low. To address these issues, this invention proposes a document processing method. This method automatically constructs a semantic difference graph connecting multiple heterogeneous data sources, enabling continuous monitoring and quantitative evaluation of the software document synchronization status. When the evaluated synchronization risk value exceeds a preset threshold, the specific target content to be updated in the document is located, and differential update information is automatically generated based on the current source code, thereby triggering the update processing flow. This transforms traditional, manual, delayed, and error-prone document maintenance into precise, proactive, and automated closed-loop management, thereby improving the accuracy and efficiency of document processing. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 1 As shown, Figure 1 A flowchart of a document processing method provided in an embodiment of the present invention includes the following steps: S110-S150.

[0015] S110. Obtain multiple heterogeneous data sources for the software project, wherein the heterogeneous data sources include at least source code and software documents associated with the source code.

[0016] Specifically, programmatic interfaces automatically collect various heterogeneous data from software projects. These heterogeneous data sources include test case data, source code, and software documentation associated with the source code. For example, in the fintech field, programmatic interfaces can automatically collect trading engine source code, compliance test cases, and related financial regulatory policy documents. In the healthcare field, they can collect the core source code of an integrated electronic health record system, test datasets for clinical decision support, and interface specification documents associated with HIPAA compliance and clinical treatment guidelines. Understandably, step S110 achieves automated collection of source code and its associated documentation, providing an accurate and complete data foundation for subsequently constructing a semantic difference map reflecting the deep connection between source code and software documentation, ensuring the validity of the input from the source.

[0017] S120. Construct a semantic difference map describing the semantic relationships between the heterogeneous data sources based on the multiple heterogeneous data sources.

[0018] Specifically, by applying a large language model, semantic encoding is performed on multi-source heterogeneous data such as source code, associated software documentation, and test cases, transforming them into quantifiable semantic vector representations. A semantic difference map is then generated based on these semantic vector representations. Intelligibly, by implementing step S120, a system capable of dynamically representing code logic, documentation descriptions, and test cases across formats and modalities is constructed. Figure 3 The structured knowledge graph that identifies deep semantic relationships and differences between users breaks through the limitations of traditional tools that can only perform text matching or format checks, and achieves intelligent analysis from "surface differences" to "semantic consistency".

[0019] Among them, such as Figure 2 As shown, step S120 includes steps S121-S123: S121. Use a large language model to perform semantic encoding on the source code, the software documentation, and the test case data to obtain semantic vector representations of each heterogeneous data source; S122. Based on the semantic vector representation, calculate the semantic similarity between different heterogeneous data sources, and convert the semantic similarity into semantic difference. S123. Using each of the heterogeneous data sources as nodes and the semantic difference degree as the weight of the edges connecting the relevant nodes, construct the semantic difference graph that represents the semantic relationship between the heterogeneous data sources.

[0020] Specifically, firstly, a large language model is used to perform deep semantic understanding and feature extraction on source code, software documentation (such as requirements documents, API interface specifications, design specifications, etc.), and test case data. Specifically, the large language model parses the function logic, data structure, and flow control of the source code, understands the business objectives, functional constraints, and interface specifications in the software documentation, and analyzes the verification intent and expected behavior of the test case data. Through the encoding layer of the large language model, heterogeneous data sources with vastly different formats, structures, and expressions are uniformly converted into semantic vector representations in a high-dimensional space. These vectors not only contain the surface information of the text but also capture the underlying technical intent and business meaning, enabling semantic comparison of data from different modalities within the same vector space. Secondly, after obtaining the semantic vector representations of each heterogeneous data source, the semantic similarity between each pair of different heterogeneous data sources is obtained by calculating the cosine similarity, Euclidean distance, or other similarity measures between the semantic vector representations. Subsequently, through a pre-defined conversion rule, the semantic similarity is mapped to a semantic difference. This difference is a quantitative indicator used to intuitively measure the semantic discrepancy or distance between two data sources. For example, completely identical semantics correspond to very low semantic dissimilarity, while contradictory or missing associations correspond to high semantic dissimilarity. It should be noted that the predefined conversion rule refers to the mathematical mapping relationship between semantic similarity (typically ranging from [0,1]) and semantic dissimilarity (typically ranging from [0,1]). The most commonly used rule is a linear inverse relationship, i.e., semantic dissimilarity = 1 - semantic similarity. When semantic similarity is 1 (completely identical), semantic dissimilarity is 0; when semantic similarity is 0 (no association), semantic dissimilarity is 1.

[0021] Finally, based on the above calculation results, a weighted directed or undirected semantic difference graph is constructed, using each heterogeneous data source (such as a specific API interface implementation code block, its corresponding interface documentation section, and the set of test cases verifying the interface) as nodes and the calculated semantic difference degree as the weight of the edges connecting related nodes. This graph dynamically and visually reveals the semantic consistency relationships and the degree of difference among the source code, software documentation, and test case data.

[0022] S130. Evaluate the synchronization risk value between the software document and the current source code based on the semantic difference graph.

[0023] Specifically, by querying the semantic difference graph, the semantic difference degree between the software document node and the node representing the current source code is extracted. Based on the semantic difference degree, a comprehensive and quantifiable synchronization risk value is calculated to objectively assess the degree of real-time disconnect between the software document and the current source code.

[0024] Among them, such as Figure 3As shown, step S130 includes steps S131-S133: S131. Calculate the semantic difference degree between the software document and the current source code based on the semantic difference graph; S132. Obtain the time decay factor of the software document since the last update and the test verification sufficiency index of the current source code; S133. Substitute the semantic difference degree, the time decay factor, and the test verification sufficiency index into the preset risk calculation formula to calculate the synchronization risk value.

[0025] Specifically, firstly, the weights of the edges connecting nodes representing software documents and nodes representing the current source code are directly queried and obtained from the constructed semantic difference graph. These weights constitute the semantic difference degree. This value directly quantifies the inconsistencies between the document description and the code implementation at deeper semantic levels, such as business logic and functional intent. A higher semantic difference degree indicates a more severe deviation and a greater baseline risk of synchronization issues. Secondly, two other dynamic indicators are obtained. One is the time decay factor, which is typically positively correlated with the length of time since the last official update of the software document. The longer the time, the larger the factor value, indicating a higher risk of the software document becoming inaccurate due to "natural obsolescence." The other is the test verification sufficiency indicator, which is usually calculated based on the current source code's test coverage, test case pass rate, and test depth. A higher indicator value indicates that the source code behavior has been thoroughly tested and verified, which can reduce the risk of misjudgment in document synchronization due to potential errors in the source code itself. Finally, the above three key indicators—semantic difference degree, time decay factor, and test verification sufficiency indicator—are substituted into a preset risk calculation formula. This risk calculation formula assigns configurable weight coefficients to each indicator and calculates a standardized, comparable synchronization risk value through weighted summation. This synchronization risk value serves as the core decision-making basis for triggering subsequent automated synchronization processes. It should be noted that the risk calculation formula is as follows: (1) In formula (1), To synchronize risk values, For semantic difference, Nodes representing software documents The node representing the current source code. The time decay factor, To test and verify sufficiency indicators, , as well as As weighting coefficients, semantic dissimilarity and time decay factors are multiplied by positive coefficients (λ, β), respectively, meaning they contribute positively to risk; that is, the greater the semantic dissimilarity and the longer the document has not been updated, the higher the risk value. The test and validation adequacy metric is multiplied by a negative coefficient (γ), meaning that sufficient test coverage can reduce synchronization risk, thus having a negative moderating effect.

[0026] In one embodiment, such as this embodiment, after step S130, the method further includes: centrally displaying the synchronous risk values ​​of multiple software documents on a risk visualization interface, and configuring interactive controls that support sorting, filtering, and setting alarm thresholds based on the synchronous risk values; responding to user interaction operations triggered by the interactive controls, performing corresponding sorting, filtering, or alarm processing, and updating the processing results in real time on the risk visualization interface for display. Specifically, in a centralized risk visualization interface, the real-time synchronous risk values ​​of all monitored software documents are displayed in the form of lists, dashboards, or topology diagrams. Simultaneously, the interface is configured with rich interactive controls: users can use the "sort" control (such as a drop-down menu or clicking the table header) to sort by synchronous risk value from high to low, quickly locating high-risk documents; use the "filter" control (such as a slider or checkbox) to set a risk value range or document type, focusing on a specific set of concerns; and use the "alarm threshold" control (such as a numeric input box or slider) to set personalized risk warning lines for different categories of documents. These controls respond instantly when the user operates them. For example, when a user clicks to sort by synchronization risk value, the interface immediately re-renders the document list order. If the user sets an alarm threshold, this threshold is compared to the continuously calculated synchronization risk value. Once the synchronization risk value of any software document exceeds the alarm threshold, the corresponding document item in the interface will be highlighted (e.g., turn red), or an alarm notification such as a pop-up or sound will be triggered. All sorted and filtered list updates, as well as real-time changes in alarm status, are immediately reflected and rendered in the risk visualization interface after user actions, providing users with a dynamic, interactive, panoramic risk view, greatly improving the efficiency and proactivity of risk management.

[0027] S140. If the synchronization risk value exceeds a preset threshold, the target content in the software document that needs to be updated synchronously is determined based on the semantic difference map.

[0028] Specifically, when the calculated synchronization risk value exceeds a preset threshold, it indicates that the disconnect between the software document and the current source code has reached a critical point requiring intervention. Then, precise difference localization is performed based on the previously constructed semantic difference graph. Specifically, first, the node representing the software document is located in the semantic difference graph, and then the subgraphs or associated nodes directly connected to it and representing source code modules are traversed. By analyzing the semantic difference weights on these connecting edges and combining them with the verification scope indicated by the associated test case nodes in the graph, specific chapters, paragraphs, or descriptions in the software document that are significantly inconsistent with the current semantic state of the code are identified, thus clearly defining these contents as target content requiring synchronization updates.

[0029] S150. Generate differential update information for updating the target content based on the current source code and the semantic difference graph, and trigger the update process of the software document based on the differential update information.

[0030] Specifically, such as Figure 4As shown, step S150 includes steps S151-S154: S151, determining the specific text location and original content corresponding to the target content in the software document based on the semantic difference graph; S152, generating updated content that matches the semantic state of the current source code by combining the semantic context parsed from the current source code, and using the specific text location, the original content, and the updated content as the differential update information; S153, formatting the differential update information into a document change request recognizable by the version control system; S154, submitting the document change request to the version control system to trigger the version update processing flow of the software document. In this embodiment, firstly, based on the semantic difference graph, not only can the target content that needs to be updated be located, but the specific text location of the target content in the software document (e.g., file path, chapter title, starting line number) can also be determined. Simultaneously, the current original content at the specific text location is extracted. Secondly, combining the semantic context of the current source code (e.g., modified function logic, newly added API parameters, changed business rules) parsed from the semantic difference graph and associated with the target content, natural language generation technology is used to intelligently synthesize an update that matches the current code's semantic state and is grammatically correct. Then, the three elements—specific text location, original content, and updated content—are encapsulated to form a structured differential update message. Next, the differential update message is formatted into a complete document change request according to the format required by the target version control system (such as Git) (e.g., generating a .patch file conforming to the UnifiedDiff format, or directly constructing a Commit object in memory). This request typically includes commit information, author, timestamp, and specific file differences, enabling it to be correctly identified and processed by the version control system. Finally, the document change request is submitted to trigger the update process. By calling the API of the version control system (such as Git's git commit and git push commands, or GitHub / GitLab's REST API), a formatted document change request is submitted to a pre-defined code repository or document repository in the version control system to trigger the downstream document version update process. For example, a merge request or pull request is generated on the collaboration platform for review. This frees people from the tedious process of finding differences, writing updates, and manually committing, and achieves automation and accuracy in document synchronization.

[0031] In one embodiment, such as this embodiment, after step S150, the method further includes: continuously monitoring the state changes of the source code in the version control system; and updating the connection edge weights of relevant nodes in the semantic difference graph in response to detecting a change in the source code. Specifically, the state changes of the source code are continuously monitored by listening to commit, push, or merge events of the version control system (such as Git). Once a new code change is detected, the modified new version of the source code is first semantically encoded in real time using a large language model to obtain its updated semantic vector representation; then, based on the new semantic vector representation, the semantic similarity between the source code node and all associated document nodes and test nodes in the semantic difference graph is recalculated and converted into a new semantic difference; finally, the weights of the corresponding connection edges in the semantic difference graph are dynamically updated using this newly calculated semantic difference. Through this process, the semantic difference graph can reflect the association state between the latest code semantics and documents and tests in real time and accurately.

[0032] For ease of understanding, the document processing method of this invention will now be illustrated with one example each from the fields of fintech and healthcare: In the fintech sector, core credit approval systems acquire heterogeneous data sources from various platforms via programmatic interfaces. For example, they obtain the latest Java / Python source code for the decision engine from GitLab, the "Anti-Money Laundering Rule V2.1" document describing the latest regulatory requirements from Confluence, and automated test scripts for the approval process for "high-risk customers" from test cases associated with Jira. A Large Language Model (LLM) is used to semantically encode these three heterogeneous data sources: the source code is parsed as logic of "if - region code in list A - then - trigger manual review"; the software documentation is understood as the rule that "applications from regions listed on the sanctions list must be transferred to manual review"; and the test cases are identified as "simulating a customer application from region A on list A and verifying whether the system raises a manual review flag." The system calculates the semantic vector similarity of the three, constructing a semantic difference graph reflecting the relationship between code logic, document rules, and test intent. When the risk control team urgently added new logic to the code for "triggering an alert if fuzzy matching similarity > 90%" to comply with new regulations, the relevant compliance documents were not updated in time. The credit approval core system detected this change by monitoring Git commits. It then recalculated the semantic differences between the new source code and the "Anti-Money Laundering Rules V2.1" document, and, considering that the document hadn't been updated for over two weeks (time decay factor) and the module's high test coverage, calculated a very high synchronization risk value. In the risk visualization interface, the software document item immediately highlighted in red and issued an alert. Because the synchronization risk value exceeded a preset threshold, the credit approval core system located the specific paragraph in the software document describing "sanctioned region matching rules" based on the semantic difference graph. Combining the semantic context of the new code ("fuzzy matching," "similarity threshold 90%), it automatically generated an update, suggesting adding "New fuzzy matching mechanism, see engine module for details" to the end of the original text. The credit approval core system formatted this update as a merge request for the Confluence page and automatically submitted it. The risk control manager receives a notification on the GitLab interface, which allows for one-click merging after review, ensuring that compliance documents and code logic are synchronized in real time. This meets the stringent requirements of internal audits and external regulators for document accuracy and avoids compliance risks caused by document lag.

[0033] In the healthcare field, the clinical decision support module of an electronic health record system (EHS) directly impacts patient safety. Code changes (such as updating the drug interaction database or adjusting clinical pathway logic) must be strictly synchronized with clinical documentation. Relevant documents include the "Clinical Drug Use Safety Rules Manual" and the "CDS Module Trigger Logic Design Document." The EHS obtains C# source code containing the latest drug contraindication checking logic, a PDF document titled "High-Risk Drug Incompatibilities Table for a Certain Year" published by the hospital's pharmacy department, and a test suite for "drug dosage adjustment in patients with renal insufficiency" from the test management tool. LLM performs deep semantic understanding on this data: it parses the rule "When a patient's creatinine clearance is <30%, the dosage of drug A is halved" from the source code; it extracts the clause "Drug A dosage needs adjustment when renal function is severely impaired" from the PDF table; and it identifies the test intent from the test cases: "Simulating a patient with a creatinine clearance of 25, verifying whether the prescribed dosage of drug A is 50% of the standard dose." By comparing the semantic vectors of these three sources, the EHS constructs a semantic difference map revealing the consistency between code implementation, clinical guidelines, and validation tests. When clinical evidence was updated, the development team modified the code, changing "Drug B" from "Contraindicated during pregnancy" to "Use with caution during pregnancy, benefit-risk ratio assessment required." However, the relevant "Clinical Drug Use Safety Rules Manual" was not revised accordingly. Upon detecting the code submission, the system immediately re-analyzed it. It found a significant semantic difference between the code's semantics ("use with caution," "assess") and the absolute "contraindicated" statement in the document. Combined with the fact that the document had been in use for several months since the last review (high time decay), despite sufficient test coverage, the calculated concurrent risk value still triggered a high-risk alert. The manual entry on the dashboard was immediately highlighted in red. Based on the semantic difference map, the "Drug B - Contraindications for Pregnant Women" section in the manual was located. Combining the new code logic and context extracted from the latest clinical literature abstracts, it generated an update suggestion, changing "contraindicated" to "use with caution," and adding the explanation that "the attending physician must assess the patient's specific benefits and risks before prescribing." The electronic health record system generated differential update information for this change and submitted it as a pull request to the Git repository hosting the manual. Upon receiving a review request, a department head can quickly verify and approve updates, thereby ensuring that the CDS logic remains strictly consistent with clinical practice guidelines and official documents consulted by medical staff. This fundamentally eliminates potential medication errors caused by outdated documents and safeguards patient safety.

[0034] The document processing method in this invention achieves continuous monitoring and quantitative evaluation of the synchronization status of software documents by automatically constructing a semantic difference graph connecting multiple heterogeneous data sources. When the evaluated synchronization risk value exceeds a preset threshold, the method locates the specific target content to be updated in the document and automatically generates differential update information based on the current source code, thereby triggering the update process. This transforms the traditional manual, slow, and error-prone document maintenance into a precise, proactive, and automated closed-loop management, thereby improving the accuracy and efficiency of document processing.

[0035] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0036] The software tools or components not belonging to our company that appear in the embodiments of this application are merely examples and do not represent actual use.

[0037] In one embodiment, a document processing apparatus 200 is provided, which corresponds one-to-one with the document processing methods described in the above embodiments. For example... Figure 5 As shown, the document processing apparatus 200 includes an acquisition unit 201, a construction unit 202, an evaluation unit 203, a determination unit 204, and a generation trigger unit 205. Detailed descriptions of each functional module are as follows: The acquisition unit 201 is used to acquire multiple heterogeneous data sources of a software project, wherein the heterogeneous data sources include at least source code and software documents associated with the source code; Construction unit 202 is used to construct a semantic difference map describing the semantic relationship between the heterogeneous data sources based on the plurality of heterogeneous data sources; Evaluation unit 203 is used to evaluate the synchronization risk value between the software document and the current source code based on the semantic difference map; The determining unit 204 is used to determine the target content in the software document that needs to be updated synchronously based on the semantic difference map if the synchronization risk value exceeds a preset threshold. The generation trigger unit 205 is used to generate differential update information for updating the target content based on the current source code and the semantic difference graph, and trigger the update process of the software document based on the differential update information.

[0038] In one embodiment, the construction unit 202 is specifically used for: The source code, software documentation, and test case data are semantically encoded using a large language model to obtain semantic vector representations of each heterogeneous data source. Based on the semantic vector representation, the semantic similarity between different heterogeneous data sources is calculated, and the semantic similarity is converted into semantic difference. Using each of the heterogeneous data sources as nodes and the semantic difference degree as the weight of the edges connecting the relevant nodes, a semantic difference graph representing the semantic relationship between the heterogeneous data sources is constructed.

[0039] In one embodiment, the evaluation unit 203 is specifically used for: Calculate the semantic difference degree between the software document and the current source code based on the semantic difference map; Obtain the time decay factor of the software documentation since the last update and the test verification sufficiency index of the current source code; The semantic difference, the time decay factor, and the test verification sufficiency index are substituted into a preset risk calculation formula to calculate the synchronization risk value.

[0040] In one embodiment, the trigger generation unit 205 is specifically used for: Based on the semantic difference map, the specific text location and original content corresponding to the target content in the software document are determined; The semantic context parsed from the current source code is combined to generate updated content that matches the semantic state of the current source code, and the specific text position, the original text content, and the updated content are used as the differential update information; The differential update information is formatted into a document change request that can be recognized by the version control system; The document change request is submitted to the version control system to trigger the version update process of the software document.

[0041] In one embodiment, the document processing apparatus 200 further includes: A monitoring unit is used to continuously monitor the state changes of the source code in the version control system. An update unit is configured to update the connection edge weights of relevant nodes in the semantic difference graph according to the changed source code in response to detecting a change in the source code. The display configuration unit is used to centrally display the synchronous risk values ​​of multiple software documents on the risk visualization interface, and to configure interactive controls that support sorting, filtering and setting alarm thresholds based on the synchronous risk values. The execution display unit is used to respond to the interactive operation triggered by the user through the interactive control, perform the corresponding sorting, filtering or alarm processing, and update the processing results in real time on the risk visualization interface for display.

[0042] The document processing device in this invention achieves continuous monitoring and quantitative evaluation of the synchronization status of software documents by automatically constructing a semantic difference graph connecting multiple heterogeneous data sources. When the evaluated synchronization risk value exceeds a preset threshold, it locates the specific target content to be updated in the document and automatically generates differential update information based on the current source code, thereby triggering the update process. This transforms the traditional manual, lagging, and error-prone document maintenance into a precise, proactive, and automated closed-loop management, thereby improving the accuracy and efficiency of document processing.

[0043] For specific limitations regarding the document processing device, please refer to the limitations on the document processing method above, which will not be repeated here. Each unit in the aforementioned document processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each of the above modules.

[0044] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a document processing method on the server side.

[0045] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the functions or steps of a document processing method on the client side.

[0046] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Acquire multiple heterogeneous data sources for a software project, wherein the heterogeneous data sources include at least source code and software documentation associated with the source code; Construct a semantic difference map describing the semantic relationships between the multiple heterogeneous data sources; The synchronization risk value between the software document and the current source code is assessed based on the semantic difference graph. If the synchronization risk value exceeds a preset threshold, the target content in the software document that needs to be synchronized and updated is determined based on the semantic difference map. Based on the current source code and the semantic difference graph, differential update information is generated to update the target content, and the update process of the software document is triggered based on the differential update information.

[0047] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Acquire multiple heterogeneous data sources for a software project, wherein the heterogeneous data sources include at least source code and software documentation associated with the source code; Construct a semantic difference map describing the semantic relationships between the multiple heterogeneous data sources; The synchronization risk value between the software document and the current source code is assessed based on the semantic difference graph. If the synchronization risk value exceeds a preset threshold, the target content in the software document that needs to be synchronized and updated is determined based on the semantic difference map. Based on the current source code and the semantic difference graph, differential update information is generated to update the target content, and the update process of the software document is triggered based on the differential update information.

[0048] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0049] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0050] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0051] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0052] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A document processing method, characterized in that, include: Acquire multiple heterogeneous data sources for a software project, wherein the heterogeneous data sources include at least source code and software documentation associated with the source code; Construct a semantic difference map describing the semantic relationships between the multiple heterogeneous data sources; The synchronization risk value between the software document and the current source code is assessed based on the semantic difference graph. If the synchronization risk value exceeds a preset threshold, the target content in the software document that needs to be synchronized and updated is determined based on the semantic difference map. Based on the current source code and the semantic difference graph, differential update information is generated to update the target content, and the update process of the software document is triggered based on the differential update information.

2. The document processing method as described in claim 1, characterized in that, The heterogeneous data source also includes test case data; the step of constructing a semantic difference graph describing the semantic relationships between the heterogeneous data sources based on the multiple heterogeneous data sources includes: The source code, software documentation, and test case data are semantically encoded using a large language model to obtain semantic vector representations of each heterogeneous data source. Based on the semantic vector representation, the semantic similarity between different heterogeneous data sources is calculated, and the semantic similarity is converted into semantic difference. Using each of the heterogeneous data sources as nodes and the semantic difference degree as the weight of the edges connecting the relevant nodes, a semantic difference graph representing the semantic relationship between the heterogeneous data sources is constructed.

3. The document processing method as described in claim 1, characterized in that, The step of assessing the synchronization risk value between the software document and the current source code based on the semantic difference graph includes: Calculate the semantic difference degree between the software document and the current source code based on the semantic difference map; Obtain the time decay factor of the software documentation since the last update and the test verification sufficiency index of the current source code; The semantic difference, the time decay factor, and the test verification sufficiency index are substituted into a preset risk calculation formula to calculate the synchronization risk value.

4. The document processing method as described in claim 1, characterized in that, The step of generating differential update information for updating the target content based on the current source code and the semantic difference graph includes: Based on the semantic difference map, the specific text location and original content corresponding to the target content in the software document are determined; The semantic context parsed from the current source code is combined to generate updated content that matches the semantic state of the current source code, and the specific text position, the original text content, and the updated content are used as the differential update information.

5. The document processing method as described in claim 1, characterized in that, The step of triggering the update process of the software document based on the differential update information includes: The differential update information is formatted into a document change request that can be recognized by the version control system; The document change request is submitted to the version control system to trigger the version update process of the software document.

6. The document processing method as described in claim 5, characterized in that, The method further includes: Continuously monitor the status changes of the source code in the version control system; In response to the detection of a change in the source code, the connection edge weights of the relevant nodes in the semantic difference graph are updated according to the changed source code.

7. The document processing method according to any one of claims 1-6, characterized in that, The method further includes: The risk visualization interface centrally displays the synchronous risk values ​​of multiple software documents and is configured with interactive controls that support sorting, filtering, and setting alarm thresholds based on the synchronous risk values. In response to the user's interactive operation triggered by the interactive control, the corresponding sorting, filtering or alarm processing is performed, and the processing results are updated in real time and displayed on the risk visualization interface.

8. A document processing apparatus, characterized in that, include: An acquisition unit is used to acquire multiple heterogeneous data sources of a software project, wherein the heterogeneous data sources include at least source code and software documents associated with the source code; The construction unit is used to construct a semantic difference map describing the semantic relationships between the heterogeneous data sources based on the multiple heterogeneous data sources; An evaluation unit is used to evaluate the synchronization risk value between the software document and the current source code based on the semantic difference graph; The determining unit is used to determine the target content in the software document that needs to be synchronously updated based on the semantic difference map if the synchronization risk value exceeds a preset threshold. A trigger generation unit is used to generate differential update information for updating the target content based on the current source code and the semantic difference graph, and to trigger the update process of the software document based on the differential update information.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the document processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the document processing method as described in any one of claims 1 to 7.

Images