An AI large model-based software development application data processing method

Abstract

The application relates to the technical field of software development data processing, and discloses a software development application data processing method based on an AI large model, which comprises the following steps: obtaining original development application data, and generating a task original data set; performing event reconstruction on the original development application data to obtain a development event sequence; performing causal correlation modeling on the development event sequence to obtain a task causal graph result; performing credibility evaluation processing on the task causal graph result to obtain a segment credibility score result, and meanwhile, performing conflict rejection processing on the task causal graph result. The development data processing technical scheme based on event reconstruction and causal correlation modeling achieves the technical effect of constructing task-level change chain consistent data, realizes the causal constraint organization of development data according to the same change chain, and solves the problem that data cannot form a credible evidence chain due to the fact that the semantics are related but do not belong to the same change chain in the prior art.

Description

Technical Field

[0001] This invention relates to the field of software development data processing technology, specifically to a software development application data processing method based on an AI large model. Background Technology

[0002] In enterprise-level software development task context data processing scenarios involving multiple repositories, multiple branches, and continuous integration access control linkage, the same development task is simultaneously associated with requirement orders, defect orders, code repositories, branch differences, commit records, pull requests, test results, dependency changes, security alerts, and runtime logs. When AI large models participate in code generation, change analysis, or defect repair, if the input data is concatenated based on text similarity, it is easy to introduce version inconsistencies, verification status inconsistencies, and data that is not actually related to changes in the current task. This causes the model output results to be inconsistent with the target branch, dependency status, and quality access control. Therefore, it is necessary to achieve task-related, version-consistent, and verification-traceable development application data processing under the conditions of continuous changes in development data and frequent version evolution.

[0003] Currently, text and code snippets are typically extracted from code repositories, requirement orders, pull requests, and related documents. The context is then organized using keyword matching, vector retrieval, or difference summarization. Multi-source information is integrated into a large AI model for analysis and processing. Additionally, code difference summarization, dependency review information, and security alerts are used to assist in generating development suggestions, thus realizing a large model application processing flow supported by multi-source development data.

[0004] Most existing technologies still organize contextual data around semantic relevance rather than constraining data around the same change chain. This allows requirement sheets, submission records, code symbols, test results, and security alerts to be acquired independently, but lacks causal constraints based on the same change chain. Consequently, the input data appears as a collection of related materials rather than a credible chain of evidence for the same task. This makes it easy for large AI models to obtain locally related but overall inconsistent data during processing, affecting the actual usability and consistency of the generated results. Therefore, to solve the above problems, this invention proposes a software development application data processing method based on a large AI model. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a data processing method for software development applications based on large AI models, thereby at least partially solving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a software development application data processing method based on an AI large-scale model, comprising:

[0007] Obtain the original development application data and generate the task's original data set;

[0008] The original development application data is reconstructed using event-based methods to obtain a development event sequence;

[0009] Causal relationship modeling was performed on the development event sequence to obtain the task cause-effect graph result;

[0010] The credibility assessment of the task cause-effect graph results is performed to obtain the segment credibility score results. At the same time, the conflict rejection processing of the task cause-effect graph results is performed to obtain the conflict rejection results.

[0011] The credibility score and conflict rejection results of the aforementioned segments are filtered and organized to obtain a restricted context packet;

[0012] The restricted context package is subjected to model inference processing to obtain the task structure processing result.

[0013] Preferably, the original development application data is reconstructed using event-based methods, including:

[0014] The original development application data is subjected to unified event abstraction processing to obtain event abstraction results;

[0015] The abstract results of the event are subjected to structured modeling to obtain the event record structure;

[0016] A preset event attribute determination strategy is used as a constraint to perform rule parsing processing on the event record structure to obtain event attribute information;

[0017] The event attribute information is subjected to association and serialization processing to obtain the development event sequence.

[0018] Preferably, causal relationship modeling is performed on the development event sequence to obtain a task causal graph result, including:

[0019] Perform node mapping processing on the development event sequence to obtain an event node set;

[0020] The sequence of development events is subjected to relationship identification processing to obtain the event association relationships;

[0021] The event node set and event relationships are processed by graph structure construction to obtain the task cause-effect graph;

[0022] The task cause-effect graph is subjected to domain association processing to obtain the task cause-effect graph result.

[0023] Preferably, the credibility assessment of the task cause-effect graph results is performed to obtain fragment credibility score results, including:

[0024] Fragment extraction is performed on the task cause-effect graph results to obtain candidate data fragments;

[0025] A preset credibility assessment strategy is used as a constraint to evaluate the candidate data segments and obtain segment evaluation feature information.

[0026] The fragment evaluation feature information is comprehensively calculated and processed to obtain the corresponding fragment confidence score result.

[0027] Preferably, the task cause-effect graph result is subjected to conflict rejection processing to obtain a conflict rejection result, including:

[0028] Fragment extraction is performed on the task cause-effect graph results to obtain candidate data fragments;

[0029] A pre-defined conflict determination strategy is used as a constraint to perform conflict identification processing on the candidate data segments, thereby obtaining conflict candidate relationships;

[0030] The conflict candidate relationships are subjected to conflict determination processing to obtain a set of conflict data fragments;

[0031] The conflicting data fragment set is subjected to rejection processing to obtain the conflict rejection result.

[0032] Preferably, the restricted context package is subjected to model inference processing to obtain the task structured processing result, including:

[0033] Construct a large AI model, input the restricted context packet into the large AI model for task parsing and processing, and obtain the model output results;

[0034] A preset result output template is used as a constraint to parse and process the model output results to obtain model output information;

[0035] The output information of the model is subjected to structured extraction processing to obtain the task structured processing result.

[0036] Preferably, the abstract result of the event is subjected to structured modeling to obtain an event record structure, including:

[0037] The abstract results of the event are divided into fields to determine the corresponding set of attribute fields;

[0038] A preset field mapping rule is used as a constraint to map the attribute field set, resulting in a field mapping result. The field mapping result is then filled into the corresponding field positions to obtain the initial event record structure.

[0039] The initial event record structure is processed to obtain a standard event record structure;

[0040] The standard event log structure is then integrated to obtain the event log structure.

[0041] Preferably, the event attribute information is subjected to association and serialization processing to obtain a development event sequence, including:

[0042] The event attribute information is subjected to association identification processing to obtain event association information;

[0043] The event attribute information is subjected to association construction processing to obtain the event association result;

[0044] The event association results are sorted sequentially to obtain the event sorting results;

[0045] The event sorting results are then processed to obtain a development event sequence.

[0046] Preferably, the event node set and event relationships are processed to construct a graph structure to obtain a task cause-effect graph, including:

[0047] Perform node configuration processing on the event node set to obtain the node configuration result;

[0048] Perform relationship configuration processing on the event associations to obtain the relationship configuration results;

[0049] Based on the node configuration results and relationship configuration results, connection construction is performed to obtain the initial graph structure;

[0050] The initial graph structure is then subjected to graph integration processing to obtain the task cause-effect graph.

[0051] Preferably, the model output information is subjected to structured extraction processing to obtain the task structured processing result, including:

[0052] The model output information is processed by field recognition to obtain a set of result fields;

[0053] The model output information is parsed to obtain field mapping results, and the field mapping results are mapped to the corresponding fields in the result field set.

[0054] The mapped field content is then standardized and organized to obtain structured field content;

[0055] The structured field content is integrated to obtain the task structured processing result.

[0056] This invention provides a data processing method for software development applications based on large AI models. It has the following beneficial effects:

[0057] 1. This invention adopts a development data processing technology solution based on event-based reconstruction and causal association modeling to achieve the technical effect of constructing consistent data of task-level change chains. It realizes that development data is organized according to the same change chain for causal constraints, which solves the shortcomings of the prior art in which semantically related data do not belong to the same change chain, resulting in the inability of data to form a credible evidence chain.

[0058] 2. This invention adopts a context generation technology based on credibility assessment and conflict exclusion constraints to achieve the technical effect of unifying branch consistency and verification status, realize the credibility constraints of multi-source development data under the branch and verification dimensions, and solve the shortcomings of the existing technology that lacks consistency and credibility judgment, resulting in data conflict and state chaos. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the process of the present invention. Detailed Implementation

[0060] To enable those skilled in the art to understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort should fall within the scope of protection of the present invention.

[0061] The present invention will now be described in detail with reference to the accompanying drawings:

[0062] Please see the appendix Figure 1 This invention provides a method for processing software development application data based on AI large-scale models, including: a method for processing software development application data based on AI large-scale models, comprising:

[0063] Obtain the original application development data and generate the task's original data set:

[0064] In this invention, raw development application data is used to characterize the original state information, change information, and verification information of the target development task in the R&D chain. The raw development application data originates from code hosting platforms, continuous integration platforms, dependency review interfaces, security scanning interfaces, and defect management systems. During collection, a task-related time window and target branch constraints are established centered on the target development task. Data within the preset time window that has an identifier association, reference association, branch association, or object association with the target development task is identified as the raw task data set.

[0065] In some implementations, the task-related time window can be determined from the task creation time to the current time; when the task spans a large area, it can be truncated according to the most recent iteration cycle or the most recent valid commit cycle. Data sources that can provide structured identifiers are prioritized during the data collection process. The target branch identifier is based on the actual delivery branch corresponding to the task to be processed, providing a basic constraint for branch consistency evaluation.

[0066] To improve the controllability of the original task dataset, task correlation can be calculated for each collected object. For example, task correlation can be expressed as:

[0067] in, This indicates the degree of association between a given original data object and the target development task. This indicates the task identifier matching result. Indicates the branch identifier matching result, Indicates the object identifier matching result. This indicates the result of the reference relationship matching. , , , This represents the weight coefficient of each matching item.

[0068] Raw data whose relevance meets preset conditions are included in the task's raw data set. This formula illustrates how to control task relevance during the data collection phase, and does not limit the implementation to a single form.

[0069] The original development application data is reconstructed using event-based methods to obtain a development event sequence:

[0070] Because the original application development data comes from heterogeneous sources, has different expression methods, and inconsistent granularity, this invention first performs unified event abstraction processing on the original application development data to obtain event abstraction results. Unified event abstraction means converting raw data from different sources into an event expression form that can be uniformly described.

[0071] In some implementations, information such as state changes, object changes, reference changes, and verification feedback changes can be uniformly abstracted into event semantic units. This event semantic unit at least reflects "who made what change to which object, when, and in what verification state." Through this abstraction, heterogeneous data originally scattered across the requirements system, code system, testing system, and security system is compressed onto the same event semantic plane.

[0072] After obtaining the abstract results of the events, the abstract results are processed through structured modeling to obtain the event record structure. The purpose of this step is to write the abstracted event content into a unified structured field system, so that different events have a consistent data structure representation.

[0073] Specifically, the abstract results of events are first divided into fields to form a set of attribute fields. Then, according to preset field mapping rules, the attribute content in the abstract results is mapped and filled into the corresponding field positions to obtain the initial event record structure. Next, the initial event record structure is standardized to eliminate format differences in time, identifier, and status representations of different events, resulting in a standard event record structure. Finally, the standard event record structure is integrated to obtain the final event record structure. The significance is that whether performing rule parsing, relationship identification, or sequence integration, it is all based on a unified record structure, rather than the original source data.

[0074] After the event record structure is formed, a preset event attribute determination strategy is used. This strategy serves as a constraint to perform rule parsing on the event record structure, yielding event attribute information. This step is used to parse attribute information from the structured event records that can directly participate in association identification and sequence organization. Event attribute information is essentially the semantically computable result of the event record structure. The event attribute determination strategy includes event type encoding logic, object identifier extraction logic, time parsing logic, and verification status determination logic.

[0075] In some implementations, event attribute parsing can be represented in the following form:

[0076] in, Indicates the first Each event record contains the corresponding event attribute information. Indicates the first An event record structure, Indicates the strategy for determining event attributes. Represents the rule parsing function.

[0077] This function allows you to obtain the task attributes, branch attributes, object attributes, reference attributes, time attributes, and verification attributes required for association identification from the event log structure.

[0078] After obtaining the event attribute information, the event attribute information is processed into an associated serialization sequence to obtain the development event sequence. This step is not a simple sorting by time, but rather first identifies the relationships between events and then forms a sequence under the constraints of these relationships.

[0079] Specifically, the event attribute information can first be associated and identified to obtain event association information. The basis for association identification can be consistent task identifiers, consistent branch identifiers, consistent object identifiers, mapping relationships between upstream references, or a reasonable temporal sequence. Next, the event attribute information is associated and constructed to obtain event association results; then, the event association results are sequentially arranged to obtain event sorting results; finally, the event sorting results are integrated into a sequence to form a development event sequence.

[0080] In some implementations, the correlation strength between events can be calculated using the following formula:

[0081] in, Indicates an event With the event The strength of the correlation between them This indicates that the task identifiers are consistent. This indicates that the branch identifiers are consistent. Indicates consistency of object identification. This indicates consistency in upstream reference relationships. and Indicates the time of the event. Indicates the time decay parameter. , , , , This represents the weighting coefficient.

[0082] Events whose correlation strength meets preset conditions can be established as sequentially related events. The purpose of this formula is to illustrate that the event sequence is not an isolated sorting result, but a serialized organization result based on correlation identification.

[0083] Causal relationship modeling was performed on the sequence of development events to obtain the task cause-effect graph results:

[0084] This invention further maps the development event sequence into a graph structure to form a task-level computable evidence chain. Specifically, the development event sequence is processed by node mapping to obtain a set of event nodes; the development event sequence is processed by relation identification to obtain event associations; the set of event nodes and event associations are processed by graph structure construction to obtain a task causal graph; and the task causal graph is then processed by domain association to obtain the task causal graph result.

[0085] In the graph structure construction process, the event node set is first configured to obtain the node configuration result; then, the event relationships are configured to obtain the relationship configuration result; next, connection construction is performed based on the node configuration result and the relationship configuration result to obtain the initial graph structure; finally, the initial graph structure is integrated to obtain the task causal graph. Graph construction includes the generation of nodes and edges, including node attributes, edge attributes, and the graph integration process after merging multiple relationships.

[0086] The task cause-effect graph is further constructed in two layers: a change domain and a verification domain. The change domain represents the code-side evolution path, while the verification domain represents the testing, pipeline, dependency, and security-side verification path. The so-called domain-based association processing involves dividing nodes and edges within the graph structure into domains based on change semantics and verification semantics, and establishing cross-constraint relationships between the two domains. This processing enables the model to distinguish between the "evolutionary path of the code change itself" and the "verification feedback path corresponding to the change's consequences," avoiding the mixing of semantically related but inconsistent change paths.

[0087] In some implementations, the causal weights of edges in the graph can be represented as:

[0088] in, Represents a node With nodes Causal edge weights between them Indicates reference drive strength. Indicates the strength of the time-sequence constraint. Indicates the strength of the verification feedback support. , , This represents the weighting coefficient.

[0089] In addition, the number of graph extension layers can be set according to the complexity of the task.

[0090] The results of the task cause-effect graph are subjected to credibility assessment and conflict rejection processing:

[0091] This invention extracts fragments from the results of the task causal graph to obtain candidate data fragments; it presets a credibility assessment strategy and uses the credibility assessment strategy as a constraint to evaluate the candidate data fragments to obtain fragment evaluation feature information; then it performs comprehensive calculation processing on the fragment evaluation feature information to obtain the fragment credibility score result.

[0092] For the credibility rating of a segment, the formula in the disclosure document can be used directly: ,

[0093] in, Indicates the first The credibility score of each candidate data segment. Represents the branch consistency coefficient. Indicates the quality access control coefficient. This represents the time difference between the candidate data segment and the current task time. Represents the aging decay constant. Indicates the coefficient of evidence support , , , This represents the weighting coefficient.

[0094] In some implementations, the above components can be further refined. For example, the evidence support coefficient can be further expressed as: ,

[0095] in, Indicates the strength of evidence support at the code symbol layer. This indicates a pull request to discuss support strength. Indicates the support strength of the test results. Indicates the strength of security or reliance on evidence. , , , This represents the weighting coefficient. This refined form is suitable for implementations that require differentiated weighting of different sources of evidence.

[0096] In addition to reliability scoring, this invention performs conflict rejection processing on the task causal graph results. Specifically, it extracts fragments from the task causal graph results to obtain candidate data fragments; it presets a conflict determination strategy, and uses this strategy as a constraint to perform conflict identification processing on the candidate data fragments to obtain conflict candidate relationships; it performs conflict determination processing on the conflict candidate relationships to obtain a set of conflict data fragments; and it performs rejection processing on the set of conflict data fragments to obtain the conflict rejection result.

[0097] In some implementations, the conflict determination score can be expressed as: ,

[0098] in, Indicates candidate fragments With candidate fragments The intensity of the conflict between them Indicates the degree of branch conflict. Indicates the degree of conflict in the unmerged change chain. Indicates the degree of conflict in failed production line batches. Indicates the degree of overriding conflict on the same code object , , , This represents the weighting coefficient. When the conflict intensity meets the preset conditions, the corresponding fragment can be marked as a member of the conflict data fragment set and excluded during context filtering.

[0099] The fragment credibility scoring results and conflict rejection results are filtered and organized to obtain a restricted context packet:

[0100] In this invention, the restricted context package is not a regular list of search results, but rather a task-level evidence chain input package generated under the dual constraints of credibility scoring and conflict exclusion. Data segments with credibility scores no lower than the credibility threshold and not falling into conflict exclusion results are selected from the task causal graph results and then organized into a restricted context package according to a three-part structure of "requirement-change-verification". Different types of data segments are not subject to a uniform fixed extraction method, but rather are selected using an allocation method based on the task type.

[0101] Specifically, the screening process includes:

[0102] The first layer is segment filtering, which retains segments whose credibility scores meet the criteria and are conflict-free.

[0103] The second layer is context organization, which involves placing fragments into requirement segments, change segments, and verification segments according to the task objectives, so that the model sees not disordered evidence, but a context with a task logical structure.

[0104] In some implementations, a context budget allocation function may be used: ,

[0105] in, Indicates assignment to the first Context budgeting of evidence fragments This indicates the importance of this type of evidence fragment in the current task. This represents the preset priority weight of the x-th type of evidence fragment. Indicates the total context budget, Indicates the first Preset weighting coefficients for evidence fragments.

[0106] In other implementations, the comprehensive admission decision for a candidate fragment to enter a restricted context packet can be expressed as: other ,

[0107] in, Indicates the first Whether a candidate data fragment enters the restricted context packet Indicates the credibility score of the segment. Indicates the confidence threshold. This indicates whether the fragment belongs to the conflict rejection result. This formula shows that context packet admission is subject to both credibility scoring and conflict rejection constraints.

[0108] Model inference is performed on the restricted context package to obtain the task structured processing results:

[0109] This invention does not directly input unconstrained raw data into the AI ​​large model. Instead, after constructing the AI ​​large model, it inputs a constrained context package into the AI ​​large model for task parsing and processing to obtain the model output results. Then, it presets the result output template and uses the result output template as a constraint to parse and process the model output results to obtain the model output information. Finally, it performs structured extraction processing on the model output information to obtain the task structured processing results.

[0110] Output field templates are pre-defined by the enterprise's R&D process to prevent output drift caused by uncontrolled model development. The results of structured task processing should include at least one of the following: target modification results, evidence chain explanation results, retesting suggestion results, dependency impact results, and risk warning results.

[0111] The purpose of the output template is to consolidate the model's output from the scattered expressions of natural language into a structured format that can be parsed, extracted, and rewritten. In other words, the model can retain its reasoning ability, but the final output format is restricted to a predefined field system, facilitating subsequent structured extraction and consistency verification.

[0112] In some implementations, the conformity of the model output to the template can be expressed as: ,

[0113] in, Indicates the conformity of the output template. Indicates the completeness of the field. Indicates the degree of conformity of field order. Indicates the degree of compliance of field content constraints. , , This represents the weighting coefficients. When the template conformity meets the preset conditions, the model output can be parsed as model output information.

[0114] When performing structured extraction processing on model output information, the following steps can be taken: First, the model output information can be processed to identify fields and obtain a set of result fields. Then, the model output information can be parsed to obtain field mapping results, and these mapping results can be mapped to the corresponding fields in the set of result fields. Next, the content of each mapped field can be standardized and organized to obtain structured field content. Finally, the structured field content can be integrated to obtain the task structured processing result.

[0115] In some implementations, field mapping reliability can be expressed as: ,

[0116] in, This indicates the reliability of the mapping for a certain field. This indicates that the field defines the matching degree. This indicates that the field content is consistent. Indicates the degree of conformity of field position. , , This represents the weighting coefficient. During structured extraction, fields whose mapping reliability meets the criteria should be prioritized.

[0117] Write-back verification of the results of the structured processing of the task:

[0118] The structured processing results of the task can be validated against the latest branch state, the latest test state, and the latest security state. If the validation passes, the result is written back to the task cause-effect graph as a new task evidence fragment. If the validation fails, the cause of the conflict is recorded and the context packet is reconstructed, ultimately obtaining the closed-loop update result of the task. This step helps to further enhance the technical effect of "verifiable, rewritable, and closed-loop processing results".

[0119] In some implementations, the write-back verification determination can be expressed as: ,

[0120] in, This indicates the write-back validity of the structured processing results. This indicates consistency with the latest branch state. This indicates consistency with the latest test status. This indicates consistency with the latest security status. , , This represents the weighting coefficient. When... When the preset conditions are met, the corresponding results can be used as new evidence fragments to write back the causal graph of the task.

[0121] Validation can be performed when the output of a large model contains target files, target symbols, test suggestions, or dependency effects; conflict determination can focus on checking whether branches have drifted, whether files have been overwritten by subsequent commits, and whether tests have become invalid in the latest pipeline.

[0122] The steps in this invention are not simply sequential, but rather have a strict input-output relationship. The original development and application data provide the initial semantic foundation for event-based reconstruction; the development event sequence provides computable event-granular input for the task causal graph; the task causal graph results provide a modified causal and verification feedback structure for credibility assessment and conflict rejection; the fragment credibility score results and conflict rejection results provide a dual screening basis for the restricted context package; the restricted context package provides constrained input for the large AI model; and the task structured processing results can serve as the final output or further enter the write-back verification closed loop. This forms a complete technology chain from raw data acquisition to verifiable output results.

[0123] Through the above technical solutions, this invention can transform the data entering the model from a "semantically related set of materials" into a "credible chain of evidence for the same task" in software development scenarios with multiple warehouses, multiple branches, and continuous integration access control linkage. Furthermore, by constraining branch consistency, quality access control status, and timeliness credibility, it significantly reduces the probability of version conflict data, expired verification data, and irrelevant similar data entering the model, thereby improving the usability, interpretability, and verifiability of the model output.

[0124] Example 1: Verification Example for Cross-Warehouse Defect Repair Tasks

[0125] This embodiment uses an online defect repair task as an example for verification. This task involves two code repositories, three branches, and two continuous integration pipelines. The task's associated time window is set to the most recent fourteen days. First, the original development application data associated with this defect task is obtained, specifically including one defect order record, one requirement supplement record, thirty-six commit records from the two code repositories, three pull request records, twenty-eight code symbol change records, sixteen test execution results, nine pipeline operation results, two dependency change records, three security alert records, and forty-two operation logs, resulting in the original task data set.

[0126] In the event-driven refactoring phase, the original task data set was subjected to unified event abstraction processing. Defect status changes, submission generation, pull request creation, file modification, test failure, pipeline success, dependency changes, and security alarm triggers were converted into standardized event expressions, resulting in 126 abstract event results. These abstract event results were then subjected to structured modeling, with fields divided and mapped according to task identifier, branch identifier, object identifier, event type, event time, upstream reference identifier, and verification status identifier, resulting in 126 event record structures. Next, a preset event attribute determination strategy was used to parse the event record structures according to rules, extracting corresponding event attribute information; for example, submission records were parsed as "target object change events," test failure records as "verification feedback events," and pipeline success records as "verification status update events." Finally, the event attribute information was subjected to association and serialization processing. Associations between events were established based on the consistency of task identifiers, branch identifiers, object identifiers, and temporal relationships, resulting in a development event sequence.

[0127] In the causal relationship modeling phase, node mapping was performed on the development event sequence, resulting in a set of 126 event nodes. Next, relationship identification was performed, identifying 208 event relationships, including relationships where requirement triggers submission, submission leads to file changes, file changes affect code symbols, code changes trigger testing, and test results are fed back to pipeline nodes. Based on the event node set and event relationships, a graph structure was constructed to form a task causal graph. The graph has three layers: the first layer contains task start nodes and submission nodes; the second layer contains file nodes and code symbol nodes; and the third layer contains test nodes, pipeline nodes, and security alert nodes. Finally, the task causal graph was divided into domains: submissions, files, code symbols, and pull requests were classified into the change domain; and test execution results, pipeline operation results, dependency changes, and security alerts were classified into the verification domain, resulting in the final task causal graph.

[0128] In the credibility assessment phase, twenty-four candidate data segments were first extracted from the task cause-effect graph results, and then the credibility scoring formula disclosed in the disclosure document was used for evaluation: ,

[0129] in, Indicates the first The credibility score of each candidate data segment. Represents the branch consistency coefficient. Indicates the quality access control coefficient. This represents the time difference between the candidate data segment and the current task time. Represents the aging decay constant. Indicates the evidence support coefficient. , , , This represents the weighting coefficient.

[0130] In this embodiment, the following is set , , , aging decay constant Daily, Trust Threshold Taking one of the candidate code snippets as an example, with a branch consistency coefficient of 1.00, a quality threshold coefficient of 0.80, a time difference of 2 days, and an evidence support coefficient of 0.9, substituting these values, we get: The first segment scored above the credibility threshold and was therefore retained. Another candidate segment from the old branch had a branch consistency coefficient of 0.4, a quality threshold coefficient of 0.3, a time difference of 10 days, and an evidence support coefficient of 0.5, resulting in a calculated score of 0.4521, which was below the credibility threshold and was therefore discarded. Through this method, eleven credible segments were ultimately retained.

[0131] During the conflict rejection phase, four sets of conflict candidate relationships are identified from the same candidate data segments. The following conflict determination formula is used for judgment: ,

[0132] in, Indicates candidate fragments With candidate fragments The intensity of the conflict between them Indicates the degree of branch conflict. Indicates the degree of conflict in the unmerged change chain. Indicates the degree of conflict in failed production line batches. Indicates the degree of overriding conflict on the same code object. , , , This represents the weighting coefficient.

[0133] In this embodiment, the following is taken , , , The conflict threshold is 0.75. For a set of two candidate fragments from the old feature branch and the target release branch, the following calculations are performed: , , , ,but: The conflict intensity exceeded the threshold, so the old feature branch segment was rejected. Ultimately, a total of five conflicting segments were rejected, resulting in the conflict rejection outcome.

[0134] During the restricted context package generation phase, the credibility score and conflict rejection results are used together for filtering, ultimately retaining nine data fragments. Combining a three-stage organization approach of "requirement-change-verification," a restricted context package is formed by organizing one defect description, one root cause analysis piece, three code symbol change fragments, two test failure pieces, two pipeline access control status pieces, and one runtime log piece. The total context budget is set at 5,400 tokens, allocated as follows: 50% for code fragments, 30% for test and pipeline evidence, and 20% for runtime logs and other evidence.

[0135] In the model processing stage, a large AI model is constructed. The restricted context package is input into the large AI model for task parsing and processing to obtain the model output results. Then, parsing is performed again using a preset output template as constraints to obtain the model output information. Finally, the model output information is structurally extracted to obtain the task structured processing results. These results include two items of target modification object information, one item of evidence chain description information, three items of retesting suggestion information, and one item of risk warning information. The results were reviewed and verified by R&D personnel. It was found that the two target files suggested by the model were consistent with the manual location results. Two of the three retesting suggestions were directly adopted, and one was adopted after adjustment. The final fixed code passed both continuous integration pipelines on the target branch in one go. This embodiment illustrates that the present invention can effectively avoid semantically related but non-participating change chain data from entering the model, improving the implementability of the output results.

[0136] Example 2: Verification Example for Dependency Upgrade and Security Remediation Tasks

[0137] This embodiment verifies a security remediation task triggered by a dependency upgrade. This task is associated with the main code repository and the public component repository, with the task association time window being the most recent 21 days. The collected raw development application data includes two requirement records, one security remediation order, twenty-two commit records, two pull request records, twelve code symbol change records, eleven test execution results, six pipeline results, five dependency change records, eight security alert records, and twenty-eight runtime logs, forming the raw data set for the task.

[0138] After event-based refactoring, a total of ninety-three event abstractions were obtained, and ninety-three event record structures were formed through structured modeling. After rule parsing, the event attribute information clearly identifies version change events related to dependency upgrades, security alarm trigger events, test pass events, and pull request aggregation events.

[0139] During causal relationship modeling, a total of 93 event nodes and 142 event relationships were mapped. The graph was expanded to four layers to cover the complete propagation chain from dependency changes to code reference point changes, and then to security alert results and test verification results. After domain-based relationship processing, dependency nodes and security alert nodes were included in the verification domain, while commit nodes, file nodes, and code symbol nodes were included in the change domain, and cross-domain influence relationships were established, resulting in the task causal graph.

[0140] During the credibility assessment, eighteen candidate data segments are extracted from the task cause-effect graph results. Considering this embodiment is a security remediation task, the following settings are made: , , , The weight of supporting evidence is appropriately increased to highlight the importance of security evidence. (Time decay constant) On that day, the trust threshold was set to 0.75. For a candidate fragment from the latest dependency upgrade commit of the target branch, the following was taken: , , day ,but:

[0141] As can be seen, this fragment has high credibility and should be included in the context packet. For a security statement fragment from an unfused old pull request, the evidence support coefficient reached 0.80, but the branch consistency was 0.35, the quality gate coefficient was 0.20, and the final score was 0.4869, so it was discarded. Through credibility assessment, a total of nine candidate fragments were retained.

[0142] During conflict exclusion, three sets of candidate conflict relationships were identified, the most typical of which was the same dependency in two different upgrade schemes. , , , The conflict threshold remains at 0.75. For this group of segments, the branch conflict degree... Unintegrated change chain conflict level Degree of conflict in failed production line batches object coverage conflict degree ,but: ,

[0143] Therefore, the corresponding segments of the old upgrade scheme are rejected, and the upgrade scheme that is consistent with the target branch and has been verified is retained.

[0144] In the construction of the restricted context package, the total context budget in this embodiment is set to 6,000 tokens. Since the task is a dependency upgrade and security remediation task, following the publicly stated principle that "the budget ratio for dependency and security evidence can be increased when version upgrades and security remediation tasks are involved," the budget is set as follows: 800 tokens for requirement descriptions, 2,500 tokens for code changes, 1,200 tokens for testing and pipeline evidence, and 1,500 tokens for dependency and security evidence. The resulting restricted context package contains one security remediation target description, three dependency change evidences, two affected code symbol evidences, one security alert evidence, two test verification evidences, and one pipeline pass evidence.

[0145] After inputting the restricted context package into the large AI model, the model output results are obtained, and model output information is formed under the constraints of the output template. Through structured extraction, the structured processing results of the task are obtained, including three items of target modification object information, two items of dependency impact information, two items of risk warning information, and two items of retesting suggestion information. One of the dependency impact information items clearly points out that there is a risk of interface compatibility changes after the upgrade. Based on this, the developers added a regression verification, and finally discovered and corrected a compatibility defect before formal integration. This shows that the present invention can provide repair suggestions and can output dependency impact and security risk warnings based on a trusted chain of evidence.

[0146] Example 3: Verification Example for Continuous Integration Access Control Failure Analysis and Retest Generation Tasks

[0147] This embodiment verifies the analysis and retesting of a failed continuous integration access control system task. This task occurred during the pre-integration inspection phase of a microservice project, and is associated with functional branches, the target integration branch, and the pipeline execution records of consecutive failures. The task's associated time window is the most recent seven days. The collected raw development application data includes one requirement record, two defect reports, twenty-nine commit records, four pull request records, nineteen code symbol change records, twenty test execution results, twelve pipeline execution results, two dependency change records, one security alert record, and fifty-six operation logs, forming the raw data set for the task.

[0148] During the event-driven refactoring phase, a total of 138 abstract event results were obtained, forming a structure of 138 event records. After rule parsing, two types of key events were clearly marked in the event attribute information: one type is "code change events," and the other type is "access control failure verification events." During the associated serialization process, events are arranged according to time order and associated based on the same test item, the same file path, and the same pipeline batch. Therefore, the resulting development event sequence can completely express the task evolution process of "commit - file change - test failure - log error - second commit - re-verification."

[0149] After causal relationship modeling, 138 event nodes and 226 event relationships were obtained. During graph structure construction, test item nodes and pipeline nodes were configured as strong verification nodes, and runtime log nodes were configured as auxiliary verification nodes to highlight the importance of verification evidence in access control failure scenarios. After domain-based association processing, test item nodes, pipeline nodes, and runtime log nodes together form a verification domain, which is then connected with the change domain containing code symbol nodes through dense cross-domain connections, resulting in the task causal graph. This result clearly characterizes "which code change caused which test failure and which runtime log anomaly."

[0150] During the credibility assessment, thirty candidate data segments were extracted from the task cause-effect graph results. Considering that the access control failure task relies more on verification evidence, therefore, [the following was selected]. , , , aging decay constant On that day, the trust threshold was set to 0.70. For the log evidence segment corresponding to a most recently failed pipeline, branch consistency was assessed. Quality access control coefficient Time difference Daily, Evidence Support Coefficient Substituting, we get: ,

[0151] This log evidence was deemed a high-confidence segment. In contrast, a test failure segment from an earlier failed batch that had been covered by subsequent submissions had a time difference of six days, a quality threshold coefficient of 0.40, and a final score of 0.5086, which was below the threshold and therefore rejected.

[0152] During conflict exclusion, five sets of conflict candidate relationships were identified, one of which consisted of overlapping relationships between the same test item in two failed pipeline rounds. This highlights the importance of batch conflicts on the production line. Regarding this relationship, , , , ,but: The test failures exceeded the conflict threshold, therefore older batch test failure segments were excluded, while the test and log evidence corresponding to the latest failed batch was retained. This prevents the model from referencing outdated failure information.

[0153] During the restricted context package construction phase, the total context budget is set at 4,800 tokens, of which 2,000 tokens are allocated to code change evidence, 1,800 tokens to test and pipeline evidence, 700 tokens to log evidence, and 300 tokens to task descriptions. The final generated restricted context package includes: one task description, two object code symbol change snippets, three pieces of latest test failure evidence, two failed pipeline access control statuses, two pieces of runtime log anomaly evidence, and one description of an existing repair attempt. For access control failure tasks, a higher proportion of the budget can be allocated to test and pipeline evidence to ensure that verification-side evidence is prioritized for entry into the model.

[0154] After inputting the aforementioned restricted context package into the AI ​​large model, the task structure processing result is obtained through task parsing, result template constraints, and structured extraction. This result provides two items of target modification object information, one item of evidence chain description information, four items of retesting suggestion information, and one item of risk warning information. Three of the four retesting suggestions were adopted by the testers, and three new regression test cases were added accordingly. After the new test cases were executed, one of them again exposed a boundary condition handling issue. The developers corrected this and resubmitted the test, resulting in all tests passing the next round of access control checks. This embodiment demonstrates that the present invention can locate the core evidence chain of access control failure and can generate practically valuable retesting suggestions based on a trusted context, verifying the practicality of the present invention in continuous integration access control linkage scenarios.

[0155] Summary of Implementation Examples:

[0156] The three embodiments described above correspond to three typical scenarios: cross-warehouse defect repair, dependency upgrade security repair, and continuous integration access control failure analysis. Specific numerical verification shows that this invention, through event-based reconstruction, causal relationship modeling, credibility assessment, conflict exclusion, restricted context package generation, and template-constrained structured model output, effectively avoids old branch data, unintegrated changed data, expired verification data, and irrelevant similar data from entering the large AI model, thereby improving the version consistency, verification traceability, and task feasibility of the model output results.

[0157] Embodiments of the present invention have been presented and described. It will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to the embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A data processing method for software development applications based on AI large-scale models, characterized in that, include: Obtain the original development application data and generate the task's original data set; The original development application data is reconstructed using event-based methods to obtain a development event sequence; Causal relationship modeling was performed on the development event sequence to obtain the task cause-effect graph result; The credibility assessment of the task cause-effect graph results is performed to obtain the segment credibility score results. At the same time, the conflict rejection processing of the task cause-effect graph results is performed to obtain the conflict rejection results. The credibility score and conflict rejection results of the aforementioned segments are filtered and organized to obtain a restricted context packet; The restricted context package is subjected to model inference processing to obtain the task structure processing result.

2. The software development application data processing method of claim 1, wherein, The original development application data is reconstructed using an event-driven approach, including: The original development application data is subjected to unified event abstraction processing to obtain event abstraction results; The abstract results of the event are subjected to structured modeling to obtain the event record structure; A preset event attribute determination strategy is used as a constraint to perform rule parsing processing on the event record structure to obtain event attribute information; The event attribute information is subjected to association and serialization processing to obtain the development event sequence.

3. The software development application data processing method of claim 1, wherein, Causal relationship modeling is performed on the development event sequence to obtain the task cause-effect graph results, including: Perform node mapping processing on the development event sequence to obtain an event node set; The sequence of development events is subjected to relationship identification processing to obtain the event association relationships; The event node set and event relationships are processed by graph structure construction to obtain the task cause-effect graph; The task cause-effect graph is subjected to domain association processing to obtain the task cause-effect graph result.

4. The software development application data processing method of claim 1, wherein, The credibility assessment of the task cause-effect graph results yields a segment credibility score, including: Fragment extraction is performed on the task cause-effect graph results to obtain candidate data fragments; A preset credibility assessment strategy is used as a constraint to evaluate the candidate data segments and obtain segment evaluation feature information. The fragment evaluation feature information is comprehensively calculated and processed to obtain the corresponding fragment confidence score result.

5. The software development application data processing method of claim 1, wherein, The conflict rejection process is applied to the task cause-effect graph results to obtain conflict rejection results, including: Fragment extraction is performed on the task cause-effect graph results to obtain candidate data fragments; A pre-defined conflict determination strategy is used as a constraint to perform conflict identification processing on the candidate data segments, thereby obtaining conflict candidate relationships; The conflict candidate relationships are subjected to conflict determination processing to obtain a set of conflict data fragments; The conflicting data fragment set is subjected to rejection processing to obtain the conflict rejection result.

6. The software development application data processing method of claim 1, wherein, The restricted context package is subjected to model inference processing to obtain the task structured processing result, including: Construct a large AI model, input the restricted context packet into the large AI model for task parsing and processing, and obtain the model output results; A preset result output template is used as a constraint to parse and process the model output results to obtain model output information; The output information of the model is subjected to structured extraction processing to obtain the task structured processing result.

7. The software development application data processing method of claim 2, wherein, The abstract results of the event are subjected to structured modeling to obtain the event record structure, including: The abstract results of the event are divided into fields to determine the corresponding set of attribute fields; A preset field mapping rule is used as a constraint to map the attribute field set, resulting in a field mapping result. The field mapping result is then filled into the corresponding field positions to obtain the initial event record structure. The initial event record structure is processed to obtain a standard event record structure; The standard event log structure is then integrated to obtain the event log structure.

8. The software development application data processing method of claim 2, wherein, The event attribute information is subjected to association and serialization processing to obtain a development event sequence, including: The event attribute information is subjected to association identification processing to obtain event association information; The event attribute information is subjected to association construction processing to obtain the event association result; The event association results are sorted sequentially to obtain the event sorting results; The event sorting results are then processed to obtain a development event sequence.

9. The software development application data processing method according to claim 3, characterized in that, The event node set and event relationships are processed by graph structure construction to obtain a task cause-effect graph, including: Perform node configuration processing on the event node set to obtain the node configuration result; Perform relationship configuration processing on the event associations to obtain the relationship configuration results; Based on the node configuration results and relationship configuration results, connection construction is performed to obtain the initial graph structure; The initial graph structure is then subjected to graph integration processing to obtain the task cause-effect graph.

10. The software development application data processing method according to claim 6, characterized in that, The model output information is subjected to structured extraction processing to obtain the task structured processing result, including: The model output information is processed by field recognition to obtain a set of result fields; The model output information is parsed to obtain field mapping results, and the field mapping results are mapped to the corresponding fields in the result field set. The mapped field content is then standardized and organized to obtain structured field content; The structured field content is integrated to obtain the task structured processing result.

Images