Research and development state updating method and device, medium, electronic equipment and program product

Abstract

The invention discloses a research and development state updating method and device, a medium, electronic equipment and a program product, and relates to the technical field of research and development management. The method comprises the following steps: monitoring a research and development event in a research and development system, and packaging the research and development event into an event data packet; generating a first state suggestion based on the event data packet; performing multi-path judgment based on the first state suggestion to generate a second state suggestion; constructing a version dependency graph based on the first state suggestion and the second state suggestion; and updating the research and development task state based on the version dependency graph. By sensing the research and development event in the multi-source research and development system and combining semantic understanding, multi-path judgment and mapping dependency modeling, linkage updating of the research and development task state is achieved, the problems of state updating lagging, dependency chain breakage and opaque version information caused by manual operation are effectively solved, and the research and development efficiency is improved. And the research and development cooperation efficiency and the state management accuracy are improved.

Description

Technical Field

[0001] This application relates to the field of R&D management technology, and in particular to a method, apparatus, medium, electronic device, and program product for updating R&D status. Background Technology

[0002] In the AI ​​R&D process, task management involves various heterogeneous events such as code submissions, dataset changes, and model registration and updates. Furthermore, tasks have complex version dependencies and collaborative relationships, making state tracking and coordination a complex management challenge that requires balancing real-time performance, accuracy, and automation. Task management systems like Jira, due to their customizable processes and strong collaborative capabilities, are widely used in R&D project management. However, traditional Jira systems lack the ability to automatically perceive and correlate multi-source events from code repositories, data version control systems, and model registration systems when facing AI R&D tasks. Task status relies entirely on manual maintenance, leading to delayed status updates, broken dependency chains, and a black box effect on version information. This makes it unsuitable for the automated requirements of real-time status linkage and version traceability in AI R&D processes.

[0003] Therefore, there is an urgent need to provide a method for updating the state of AI R&D tasks that can realize multi-source event perception, version dependency tracking, and task state updates. Summary of the Invention

[0004] This application provides a method, apparatus, medium, electronic device, and program product for updating the status of research and development.

[0005] Firstly, this application provides a method for updating the research and development status, comprising the following steps: Monitor R&D events in the R&D system and encapsulate these events into event data packets; Generate a first-state suggestion based on the event data packet; Based on the first state suggestion, multi-path judgment is performed to generate a second state suggestion; Based on the first and second state recommendations, construct a version dependency graph; Update the development task status based on the version dependency graph.

[0006] In some embodiments, the R&D system includes at least one of a code repository system, a data version control system, and a model registration system.

[0007] In some embodiments, R&D events include at least one of code submission events, dataset change events, model registration events, and model update events.

[0008] In some embodiments, generating a first state suggestion based on an event data packet includes: Process the event data packets to obtain the task type and event source; Generate a first-state suggestion based on the task type and event source.

[0009] In some embodiments, a first state suggestion is generated based on the task type and event source, including: Based on preset state mapping rules, the first state suggestion corresponding to the R&D event is determined according to the task type and event source.

[0010] In some embodiments, the state mapping rules include at least one of the following: AI model training task mapping rules, AI model evaluation task mapping rules, and AI data preprocessing task mapping rules.

[0011] In some embodiments, multi-path determination based on the first state suggestion includes at least one of: determining whether container snapshot verification is required, determining whether the current task has an incomplete model version dependency, and determining whether the current task has an incomplete related task dependency.

[0012] In some embodiments, when it is determined that container snapshot verification is required, the metadata of historical container snapshots is obtained, the current task environment is compared with the metadata, and a second state suggestion is generated based on the comparison result.

[0013] In some embodiments, comparing the current task environment with metadata includes: performing a consistency comparison of at least one of the container image version, script content hash value, data check value, and dependency library version.

[0014] In some embodiments, determining whether there are incomplete model version dependencies in the current task includes: querying the model registration status recorded in the version dependency graph.

[0015] In some embodiments, constructing a version dependency graph includes: The first and second state suggestions are quantitatively scored to obtain the integrated state score. Based on the integrated state score and task type, the target graph paradigm is determined from multiple preset graph paradigms; Construct a version dependency graph according to the target graph paradigm.

[0016] In some embodiments, the version dependency graph includes the relationships between code versions, data versions, and model versions.

[0017] In some embodiments, the preset graph paradigm includes at least one of full-chain association graphs, dynamic dependency graphs, and conflict isolation graphs.

[0018] In some embodiments, the target map paradigm is determined based on the numerical range of the integrated status score and the task type.

[0019] In some embodiments, the full-chain relational graph includes a unidirectional chain dependency path formed between code version nodes, model version nodes, and data version nodes.

[0020] In some embodiments, a dynamic dependency graph includes evaluating the dependencies between task nodes and multiple parallel combinations of model version nodes and data version nodes.

[0021] In some embodiments, the conflict isolation graph includes isolation zone nodes, which are positioned between the node that detects the version conflict and the downstream task node; wherein the node with the version conflict includes at least one of code version nodes, model version nodes, and data version nodes.

[0022] In some embodiments, updating the R&D task status based on the version dependency graph includes: Identify the graph paradigm to which the version dependency graph belongs; According to the traversal rules corresponding to the graph paradigm, the traversal version depends on the nodes in the graph; Based on the traversal results, update the R&D task status corresponding to the node.

[0023] In some embodiments, when the graph paradigm is a fully linked graph, a depth-first search is used for traversal; when the graph paradigm is a conflict-isolated graph, a breadth-first search is used for traversal.

[0024] In some embodiments, updating the R&D task status corresponding to a node based on the traversal results includes: When the dependencies of a node are determined to meet the conditions, the status of the downstream R&D tasks associated with that node is updated to the executable state. When a conflict or unmet dependency is encountered during node traversal, the status of the associated R&D task is updated to require manual intervention.

[0025] Secondly, this application provides a research and development status update device, comprising: The event awareness module is configured to listen for development events in the development system and encapsulate these events into event data packets. The state resolution module is configured to generate a first state suggestion based on event data packets; The flow control module is configured to perform multi-path judgment based on the first state suggestion, generate a second state suggestion, and update the R&D task status based on the version dependency graph. The graph construction module is configured to build a version dependency graph based on the first state suggestion and the second state suggestion. The snapshot verification module is configured to perform task environment comparison based on the metadata of historical container snapshots when verifying container snapshots in multi-path judgment.

[0026] In some embodiments, the state resolution module includes: The packet processing submodule is configured to process event packets to obtain the task type and event source; The rule mapping submodule is configured to determine the first state suggestion based on preset state mapping rules, according to the task type and event source.

[0027] In some embodiments, the flow control module includes: The multi-path judgment submodule is configured to perform at least one of the following operations based on the first state suggestion: container snapshot verification judgment, model version dependency judgment, and related task dependency judgment. The graph-driven update submodule is configured to traverse the nodes in the version dependency graph based on the version dependency graph, and update the R&D task status corresponding to the node according to the traversal results.

[0028] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any one of the research and development status update methods.

[0029] Fourthly, this application provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement any of the research and development status update methods.

[0030] Fifthly, this application provides a computer program product, including a computer-readable storage medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements any of the research and development status update methods.

[0031] The above-mentioned at least one technical solution adopted in the embodiments of this application can achieve the following beneficial effects: by listening to events of multi-source R&D systems and encapsulating them into event data packets, timely perception of the R&D process is realized; further, by generating a first state suggestion through semantic understanding and rule mapping, and generating a second state suggestion based on multi-path judgment, the analysis of the impact of events and the tracking of dependencies are realized; further, based on the first state suggestion and the second state suggestion, a version dependency graph is constructed; finally, the update of the R&D task status is realized based on the version dependency graph, which fundamentally solves the problems of lag, broken dependency chains and version black boxes caused by manual updates, and significantly improves the efficiency of R&D collaboration and the accuracy of status management.

[0032] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0033] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The accompanying drawings are used to provide a further understanding of the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the accompanying drawings, the same reference numerals generally represent the same components or steps.

[0034] Figure 1 This illustration schematically shows an overall process diagram of a research and development status update method according to an embodiment of this application; Figure 2 This illustration schematically shows a first state suggestion generation process of a research and development state update method according to an embodiment of this application; Figure 3 This illustration schematically shows a second state suggestion generation process of a research and development state update method according to an embodiment of this application; Figure 4 This illustration schematically shows a version dependency graph construction process of a research and development status update method according to an embodiment of this application; Figure 5 This illustration schematically shows a schematic diagram of the research and development task status update process according to an embodiment of the present application; Figure 6 This illustration schematically shows an overall structural diagram of a research and development status update device according to an embodiment of this application; Figure 7 This illustration schematically shows a structural diagram of the state parsing module of a research and development state update device according to an embodiment of this application; Figure 8 This illustration schematically shows a flow control module structure of a research and development status update device according to an embodiment of this application; Figure 9 An exemplary block diagram of a computer program product of a research and development status update method according to an embodiment of this application is shown schematically.

[0035] In the diagram: 601, Event Awareness Module; 602, State Resolution Module; 603, Flow Control Module; 604, Graph Construction Module; 605, Snapshot Verification Module; 606, Data Packet Processing Submodule; 607, Rule Mapping Submodule; 608, Multi-Path Judgment Submodule; 609, Graph-Driven Update Submodule; 901, Computer Program. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application more apparent, exemplary embodiments according to this application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0037] Figure 1 The illustration shows an overall flowchart of a research and development status update method according to an embodiment of this application.

[0038] like Figure 1 As shown, the steps include: S101 listens for development events in the development system and encapsulates these events into event data packets. Specifically, it listens for events related to development tasks through event probes or hooks deployed in external development systems such as code repository systems, data version control systems, and model registration systems. These events include, but are not limited to, code commits, dataset version changes, and model registration and updates. When an event is detected, its relevant information is captured and encapsulated into an event data packet for subsequent processing and transmission.

[0039] S102, Generate a first state suggestion based on the event data packet. The event data packet is received and parsed. By extracting and semantically understanding key fields such as submission information, change type, and associated task identifier, the type of R&D task associated with the current event and its specific event source are determined. Based on preset state mapping rules, the event is interpreted in context to generate a semantically oriented first state suggestion. This first state suggestion is used to initially describe the potential impact of the event on the task state.

[0040] S103, perform multi-path judgment based on the first state suggestion to generate a second state suggestion. Based on the context of the first state suggestion, multi-path judgment is performed, mainly including: determining whether container snapshot verification is needed, determining whether the current task has unmet model version dependencies, and determining whether there are incomplete related task dependencies. Based on the judgment results, a second state suggestion including execution constraints or dependencies is generated.

[0041] S104. Based on the first and second state suggestions, construct a version dependency graph. Quantitatively evaluate and weight the first and second state suggestions to obtain an integrated state score that comprehensively reflects the current health and dependency status of the task. Combining the task type with this integrated state score, select the most suitable target graph paradigm from several preset graph paradigms, such as fully chained, dynamic dependency, and conflict isolation. Construct a version dependency graph based on the selected target graph paradigm.

[0042] S105, Update the Development Task Status Based on the Version Dependency Graph. Identify the graph paradigm used by the version dependency graph, and traverse and analyze the nodes in the graph according to the graph traversal rules corresponding to that paradigm. Based on the verified dependency satisfaction or discovered conflict nodes during the traversal, perform corresponding status update operations: for example, when all dependency conditions are met, update the status of downstream related tasks to executable; when version conflicts or missing dependencies are detected, mark the relevant task status as requiring manual intervention.

[0043] Figure 2 The illustration shows a schematic diagram of the first state suggestion generation process of a research and development state update method according to an embodiment of this application.

[0044] like Figure 2 As shown, the steps include: S201 processes the event data packet, extracting and parsing key fields to obtain the task type and event source. Key fields are extracted from the event data packet, such as commit hashes and commit messages from the code repository, data version identifiers and change types from the data version control system, and model names and version numbers from the model registration system. Through parsing and semantic analysis, the extracted relevant information is converted into identifiable standardized parameters. Specifically, based on keywords, change type identifiers, and the event source system type in the commit message or description fields, pattern matching and searching a predefined mapping table are used to determine the specific type of R&D task associated with the current event and record the specific source of the event, providing structured contextual information for subsequent decision-making.

[0045] S202: Based on preset state mapping rules, and according to the task type and event source, generate a first state suggestion corresponding to the R&D event. Taking the obtained task type and event source as input, call a preset state mapping rule library associated with the task type. This state mapping rule library contains pre-defined semantic suggestion mapping relationships for different combinations of task types and event sources. Based on the current task type and event source, perform a rule matching operation to determine the corresponding mapping rule from the state mapping rule library, and then generate a first state suggestion corresponding to the current event context according to the logic of the rule, thereby completing the transformation from the original event to a semantic state judgment.

[0046] Figure 3 The illustration shows a schematic diagram of the second state suggestion generation process of a research and development state update method according to an embodiment of this application.

[0047] like Figure 3 As shown, the steps include: S301, based on the first state suggestion, determines whether container snapshot verification is needed. It receives the first state suggestion and parses its semantic content. Based on predefined judgment rules, when the first state suggestion indicates changes to core assets such as code and data, it determines that container snapshot verification is needed to ensure the consistency of the execution environment for subsequent tasks.

[0048] S302, If container snapshot verification is required, obtain the metadata of historical container snapshots. Based on the determination result, perform container snapshot verification. Based on the identifier of the current task, retrieve and load the historical container snapshot generated during the last stable run associated with that task. Extract the complete environment metadata stored in the snapshot, including detailed information such as container image version, execution script hash value, data checksum, and dependency library list.

[0049] S303: Perform a consistency comparison between the current task environment and the metadata to obtain the comparison results. Obtain the real-time environment parameters for the scheduled task execution. Compare the current task environment's image version, script hash, data checksum, and list of dependent library versions with the corresponding metadata extracted from historical snapshots item by item, record the matching status of each item, and identify items with discrepancies.

[0050] S304. Based on the comparison results, generate a second state suggestion. If all items match, a second state suggestion allowing the state update is generated. If a difference is found, a second state suggestion pointing to the specific environment change is generated, such as image version change, script content change, data content change, or dependency library version conflict.

[0051] Figure 4 The illustration shows a schematic diagram of the version dependency graph construction process of a research and development status update method according to an embodiment of this application.

[0052] like Figure 4 As shown, the steps include: S401, quantify and score the first and second state suggestions to obtain an integrated state score. The various state information contained in the first and second state suggestions are quantified and assigned values ​​according to a predefined scoring mapping table. This scoring mapping table assigns positive or negative scores to different semantic suggestions and validation results generated based on state mapping rules. The weighted sum of all relevant state information scores is calculated to obtain an integrated state score that comprehensively reflects the current health status and dependency satisfaction of the task.

[0053] The formula for the integrated state scoring vector is shown in Formula 1: (Formula 1) By integrating state score vectors The first and second state proposals are quantized and transformed, where m This indicates the amount of state information suggested in the first state. The quantitative scores corresponding to each item in the first state suggestion; n This indicates the amount of state information included in the second state suggestion. The quantitative scores correspond to each item in the second state recommendation.

[0054] The weighted calculation formula for the integrated status score is shown in Formula 2: (Formula 2) Integration status score A comprehensive evaluation of the information contained in the first and second type of state proposals is achieved through weighted summation, whereby... Suggest dynamic weights for the first state. This represents the dynamic weight corresponding to the second-state proposal. This calculation process transforms qualitative descriptions into quantitative indices by quantifying semantically derived state proposals, thus providing a basis for subsequent integrated state scoring. The numerical range matching target graph paradigm provides a basis for ensuring that the construction of the version dependency graph is aligned with the actual health and dependency status of the task.

[0055] S402, based on the integration status score and task type, determine the target graph paradigm from multiple preset graph paradigms. According to the matching rules between the numerical range of the integration status score and the specific task type, select the target graph paradigm that best suits the current situation. The graph paradigms include fully chained, dynamically dependent, and conflict-isolated types.

[0056] S403. Construct a version dependency graph according to the target graph paradigm. Based on the construction logic of the selected target graph paradigm, extract node and edge information from events and metadata. If the target graph paradigm is a fully chained association type, construct unidirectional dependency chains of code version nodes, model version nodes, and data version nodes in sequence. If it is a dynamic dependency type, create dependencies between the evaluation task and multiple sets of parallel version combinations and calculate path weights. If it is a conflict isolation type, insert isolation zone nodes between nodes where conflicts are detected and downstream tasks. Finally, generate the corresponding version dependency graph.

[0057] Figure 5 The illustration shows a schematic diagram of the research and development task status update process according to an embodiment of the present application.

[0058] like Figure 5 As shown, the steps include: S501 identifies the graph paradigm to which the generated version dependency graph belongs. By parsing the metadata of the constructed version dependency graph and analyzing its overall structural characteristics, the specific construction paradigm adopted is identified.

[0059] S502, following the traversal rules corresponding to the graph paradigm, traverse the nodes in the version dependency graph. Based on the identified graph paradigm, use the corresponding graph traversal algorithm to traverse the nodes. For graphs with chained structures, depth-first search is used, checking sequentially along dependency edges. For graphs with isolated regions, breadth-first search is used, assessing the broad impact on downstream regions starting from conflict points. During traversal, check the version consistency, dependency satisfaction status, and conflict flags of the nodes.

[0060] S503: Based on the traversal results, update the R&D task status corresponding to the node. If all upstream dependencies of a task node are verified to be consistent and satisfied, and no conflicts are found, the status of the task and its direct downstream tasks will be automatically updated to executable update. If the traversal detects version mismatch, missing dependencies, or conflict markers, the status of the relevant tasks will be updated to require manual intervention, and their automatic progress will be paused.

[0061] Figure 6 The schematic diagram illustrates the overall structure of a research and development status update device according to an embodiment of this application.

[0062] like Figure 6 As shown, the device includes an event sensing module 601, a state parsing module 602, a flow control module 603, a graph construction module 604, and a snapshot verification module 605.

[0063] Among them, the event sensing module 601 is configured to listen to R&D events in the R&D system and encapsulate the R&D events into event data packets.

[0064] The state resolution module 602 is configured to generate a first state suggestion based on event data packets.

[0065] The flow control module 603 is configured to perform multi-path judgment based on the first state suggestion, generate a second state suggestion, and update the R&D task status based on the version dependency graph.

[0066] The graph construction module 604 is configured to build a version dependency graph based on the first state suggestion and the second state suggestion.

[0067] The snapshot verification module 605 is configured to perform task environment comparison based on the metadata of historical container snapshots when verifying container snapshots in multi-path judgment.

[0068] Figure 7The illustration shows a schematic diagram of the state parsing module structure of a research and development state update device according to an embodiment of this application.

[0069] like Figure 7 As shown, the state parsing module 602 includes a packet processing submodule 606 and a rule mapping submodule 607.

[0070] The packet processing submodule 606 is configured to process event packets to obtain the task type and event source.

[0071] The rule mapping submodule 607 is configured to determine the first state suggestion based on the preset state mapping rules, according to the task type and event source.

[0072] Figure 8 The schematic diagram illustrates the flow control module structure of a research and development status update device according to an embodiment of this application.

[0073] like Figure 8 As shown, the flow control module 603 includes a multi-path judgment submodule 608 and a graph-driven update submodule 609.

[0074] The multi-path judgment submodule 608 is configured to perform at least one of the following operations based on the first state suggestion: container snapshot verification judgment, model version dependency judgment, and associated task dependency judgment.

[0075] The graph-driven update submodule 609 is configured to traverse the nodes in the version dependency graph based on the version dependency graph, and update the R&D task status corresponding to the node according to the traversal results.

[0076] Figure 9 An exemplary block diagram of a computer program product of a research and development status update method according to an embodiment of this application is shown schematically.

[0077] like Figure 9 As shown, the computer program product stores a computer program 901, which, when executed by a processor, implements the method provided in any embodiment of this application.

[0078] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0079] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0080] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0081] It should also be noted that in the system and method of this application, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions of this application.

[0082] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this application is not limited to the specific aspects of the processes, machines, manufacturing, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufacturing, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described above can be utilized. Therefore, the appended claims include such processes, machines, manufacturing, events, means, methods, or actions within their scope.

[0083] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this application. Therefore, this application is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0084] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for updating the research and development status, characterized in that, Includes the following steps: Monitor R&D events in the R&D system and encapsulate the R&D events into event data packets; A first state suggestion is generated based on the event data packet; Based on the first state suggestion, multi-path judgment is performed to generate a second state suggestion; Based on the first state suggestion and the second state suggestion, construct a version dependency graph; Update the R&D task status based on the aforementioned version dependency graph.

2. The R&D status update method according to claim 1, characterized in that, The R&D system includes at least one of a code repository system, a data version control system, and a model registration system.

3. The R&D status update method according to claim 1, characterized in that, The R&D events include at least one of the following: code submission events, dataset change events, model registration events, and model update events.

4. The R&D status update method according to claim 1, characterized in that, Generating the first state suggestion based on the event data packet includes: The event data packet is processed to obtain the task type and event source; The first state suggestion is generated based on the task type and the event source.

5. The R&D status update method according to claim 4, characterized in that, Based on the task type and the event source, the first state suggestion is generated, including: Based on preset state mapping rules, the first state suggestion corresponding to the R&D event is determined according to the task type and the event source.

6. The R&D status update method according to claim 5, characterized in that, The state mapping rules include at least one of the following: AI model training task mapping rules, AI model evaluation task mapping rules, and AI data preprocessing task mapping rules.

7. The R&D status update method according to claim 1, characterized in that, Based on the first state, a multi-path determination is proposed, including: determining whether container snapshot verification is required, determining whether the current task has an incomplete model version dependency, and determining whether the current task has an incomplete related task dependency.

8. The R&D status update method according to claim 7, characterized in that, When it is determined that container snapshot verification is required, the metadata of historical container snapshots is obtained, and the current task environment is compared with the metadata. Based on the comparison result, the second state suggestion is generated.

9. The R&D status update method according to claim 8, characterized in that, The current task environment is compared with the metadata, including: a consistency comparison of at least one of the following: container image version, script content hash value, data verification value, and dependency library version.

10. The R&D status update method according to claim 7, characterized in that, Determining whether there are any incomplete model version dependencies in the current task includes: querying the model registration status recorded in the version dependency graph.

11. The R&D status update method according to claim 5, characterized in that, Constructing the version dependency graph includes: The first state suggestion and the second state suggestion are quantitatively scored to obtain the integrated state score; Based on the integrated status score and the task type, a target graph paradigm is determined from multiple preset graph paradigms; Construct the version dependency graph according to the target graph paradigm.

12. The R&D status update method according to claim 11, characterized in that, The version dependency graph includes the relationships between code versions, data versions, and model versions.

13. The R&D status update method according to claim 11, characterized in that, The preset graph paradigm includes at least one of the following: full-chain association graph, dynamic dependency graph, and conflict isolation graph.

14. The R&D status update method according to claim 11, characterized in that, The target map paradigm is determined based on the numerical range of the integrated status score and the task type.

15. The R&D status update method according to claim 13, characterized in that, The full-chain relational graph includes unidirectional chain dependency paths formed between code version nodes, model version nodes, and data version nodes.

16. The R&D status update method according to claim 13, characterized in that, The dynamic dependency graph includes evaluating the dependencies between task nodes and multiple parallel combinations of model version nodes and data version nodes.

17. The R&D status update method according to claim 13, characterized in that, The conflict isolation graph includes isolation zone nodes, which are set between the node that detects the version conflict and the downstream task node; wherein, the node with the version conflict includes at least one of code version nodes, model version nodes and data version nodes.

18. The R&D status update method according to claim 1, characterized in that, Updating the R&D task status based on the version dependency graph includes: Identify the graph paradigm to which the version dependency graph belongs; The nodes in the version dependency graph are traversed according to the traversal rules corresponding to the graph paradigm. Based on the traversal results, update the R&D task status corresponding to the node.

19. The R&D status update method according to claim 18, characterized in that, When the graph paradigm is a fully linked graph, a depth-first search is used for traversal; when the graph paradigm is a conflict-isolation graph, a breadth-first search is used for traversal.

20. The R&D status update method according to claim 18, characterized in that, Update the R&D task status corresponding to the node based on the traversal results, including: When the traversal determines that the dependency relationship of the node meets the condition, the status of the R&D task associated with the downstream of the node is updated to the executable state. When a conflict or unmet dependency is found when traversing the node, the status of the associated R&D task is updated to require manual intervention.

21. A research and development status update device, characterized in that, include: The event awareness module is configured to listen for R&D events in the R&D system and encapsulate the R&D events into event data packets. The state resolution module is configured to generate a first state suggestion based on the event data packet; The flow control module is configured to perform multi-path judgment based on the first state suggestion, generate a second state suggestion, and update the R&D task status based on the version dependency graph; The graph construction module is configured to construct the version dependency graph based on the first state suggestion and the second state suggestion; The snapshot verification module is configured to perform task environment comparison based on the metadata of historical container snapshots when verifying container snapshots in the multi-path judgment.

22. The R&D status update device according to claim 21, characterized in that, The state resolution module includes: The data packet processing submodule is configured to process the event data packets to obtain the task type and event source; The rule mapping submodule is configured to determine the first state suggestion based on the preset state mapping rules, according to the task type and the event source.

23. The R&D status update device according to claim 21, characterized in that, The flow control module includes: The multi-path judgment submodule is configured to perform at least one of the following operations based on the first state suggestion: container snapshot verification judgment, model version dependency judgment, and related task dependency judgment. The graph-driven update submodule is configured to traverse the nodes in the version dependency graph based on the version dependency graph, and update the R&D task status corresponding to the node according to the traversal results.

24. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the research and development status update method according to any one of claims 1 to 20.

25. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the research and development status update method according to any one of claims 1 to 20.

26. A computer program product comprising a computer-readable storage medium on which a computer program is stored, characterized in that, When the computer program is executed by the processor, it implements the research and development status update method according to any one of claims 1 to 20.

Images