Intelligent agent collaborative code generation data synthesis method for large model training

Abstract

The application discloses a double-agent collaborative code generation data method for large model training, comprising the following steps: inputting a composite prompt composed of requirements, regulations and blood tokens into a generation agent to generate an initial code sample; verifying the agent to calculate three types of probabilities through semantic graph extraction and triple cross attention; if the joint probability is lower than a threshold, constructing a negative reward gradient backpropagation to update the adapter and generate an additional sample, and splicing the initial sample and the additional sample into a merged sample according to blood tracing; if the verification does not meet the threshold, the loop is corrected until the threshold or the iteration upper limit is met, and a final code sample is obtained; and finally, the final code sample and the three types of tokens are packaged into a four-tuple training sample and written into a data pool. The application can form code training data with controllable quality, unified structure, traceable blood and easy and efficient calling without relying on a large amount of manual checking.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a dual-agent collaborative code synthesis data generation method for training large models. Background Technology

[0002] With the widespread application of large-scale pre-trained models in the field of code generation, model performance largely depends on the quality of training data. However, existing technologies still face several limitations when synthesizing training samples: (1) Unstable sample quality. Generated models often cannot ensure the consistency of output code in terms of syntax, semantics, specifications, and dependencies, resulting in a large number of uncompileable or non-compliant samples. (2) The verification process heavily relies on manual labor. Current data cleaning and quality auditing usually require developers to perform manual checks, such as syntax verification, specification comparison, and logical association confirmation, which is inefficient and costly. (3) Error samples cannot be automatically corrected. Existing generation methods generally lack automated error location and local completion mechanisms. Once the generated results do not meet the standards, they can only be discarded directly, resulting in low utilization of training data. (4) The lineage of training samples is untraceable. It is difficult to record the sample generation path, version changes, and the relationship between the sample and the requirement specifications, affecting the judgment of the data source and reliability when fine-tuning the model later. (5) The data pool lacks structured management and efficient calling mechanisms. Generated samples are usually stored in unstructured formats, making it difficult to achieve on-demand retrieval and efficient scheduling.

[0003] The aforementioned problems collectively make it difficult for existing technologies to generate datasets that are of stable quality, uniform in format, automatically correctable, and traceable in large-scale production scenarios, thus limiting the training efficiency and effectiveness of large model fine-tuning.

[0004] Therefore, there is an urgent need in this field for an automatic code generation data synthesis method that can automatically perform quality verification, automatically correct erroneous samples, construct traceable lineage chains, and support structured high-speed writing and retrieval, so as to achieve a training data construction process that is quality-controllable, structurally unified, traceable in lineage, and easy to call efficiently without the need for a large amount of manual verification. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a dual-agent collaborative code generation data method for training large models.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] This invention discloses a dual-agent collaborative code generation data method for training large models, comprising the following steps:

[0008] Step 1: Input the composite cue vector containing demand token, specification token and lineage token into the generating agent. The generating agent outputs the candidate code token sequence autoregressively through a heterogeneous decoding stack composed of a backbone decoder with frozen weights and an adapter connected in series, forming the initial code sample.

[0009] Step 2: Inject the initial code sample into the parallel verification pipeline driven by the verification agent. The verification agent calls the semantic encoder, which shares weights with the generating agent, to extract the graph structure of the initial code sample to obtain the abstract syntax tree token and the data flow graph token. The abstract syntax tree token, the data flow graph token, and the requirement token are then subjected to ternary cross-attention calculation to generate the compilation success probability, specification compliance probability, and lineage integrity probability in real time.

[0010] Step 3: When the joint probability of compilation success, specification compliance, and lineage integrity is lower than a preset threshold, the verification agent encodes the misalignment of the abstract syntax tree token, data flow graph token, and initial code sample into a negative reward gradient, and backpropagates the negative reward gradient to the adapter of the generating agent through the backpropagation channel to achieve real-time weight updates. After correction, the agent is generated.

[0011] Step 4: After correction, the generated agent replaces the misaligned positions of the initial code sample with a mask according to the negative reward gradient, re-decodes the supplementary code sample, and splices the supplementary code sample with the initial code sample according to the tracing identifier recorded in the lineage token to form a merged code sample with an incremental lineage chain.

[0012] Step 5: The verification agent executes the parallel verification pipeline again on the merged code sample. If the joint probability reaches the preset threshold, the merged code sample is output. If it still does not reach the threshold, the merged code sample is marked as the secondary initial code sample and steps 2 to 4 are executed repeatedly until the joint probability reaches the preset threshold or the number of iterations reaches the upper limit, and the final code sample is obtained.

[0013] Step 6: Encapsulate the final code sample and its corresponding requirement token, specification token and complete lineage token into a four-tuple training sample, and write it into the data pool for training large models, for subsequent full fine-tuning of the generative agent backbone decoder.

[0014] Furthermore: Step 1 includes:

[0015] Step 1-1: In the offline phase, a rule-neural network hybrid extractor is used to parse the license-cleaned compliant source code library file by file. For each function-level code snippet, a requirement token is generated using the function signature as the anchor. The requirement token is a fixed-length 768-dimensional vector representation composed of a natural language description of the function's functionality, a list of input and output tensor shapes, and an industry standard identifier. Simultaneously, an abstract syntax tree traversal and a data flow graph traversal are performed on the source code with the same function signature. The node attributes obtained from the traversal are serialized into a specification token. The specification token is a fixed-length 1024-dimensional vector representation composed of an abstract syntax tree node type sequence, a data flow graph edge type sequence, and a security criticality level marker. Subsequently, a globally unique lineage token is generated based on the Git commit hash, repository URI, and starting line number. The lineage token is a 256-bit binary vector representation composed of a 160-bit SHA-1 hash value, a 32-bit timestamp, and a 16-bit license number.

[0016] Steps 1-2: Concatenate the demand token, specification token, and lineage token column-wise to form a composite cue vector, and insert a learnable separator embedding at the concatenation point to obtain a composite cue vector with dimensions (3, 768); input the composite cue vector into the generating agent, which consists of a heterogeneous decoding stack composed of a frozen weighted LLaMA-3 8B backbone decoder and a low-rank adapter containing only 0.1% trainable parameters, wherein the low-rank adapter uses a LoRA matrix with a rank of 16 to bypass the Query and Value projection layers of the backbone decoder;

[0017] Steps 1-3: In the autoregressive generation stage, the heterogeneous decoding stack uses a temperature annealing sampling strategy to decode the composite cue vector with a linear annealing temperature of 0.8→0.2, outputting a candidate code token sequence with a maximum length of 512. After restoring the candidate code token sequence by inverse mapping of the vocabulary and whitespace characters, an initial code sample that can be directly sent to the compiler is obtained. The initial code sample is a plain text string encoded in UTF-8, with a lineage token hexadecimal representation appended to its beginning and end as an uncompileable comment for rapid source tracing in the subsequent verification stage.

[0018] Furthermore: Step 2 includes:

[0019] Step 2-1: Inject the initial code sample into the parallel verification pipeline driven by the verification agent. The parallel verification pipeline consists of three parallel processes: a compiler container pool, a static specification checking engine, and a lineage tracing microservice. The three processes share the same POSIX message queue and read the memory image of the initial code sample in a zero-copy manner.

[0020] Step 2-2: Verify the semantic encoder that shares the weights of the agent calling and generating the agent. Extract the graph structure from the initial code sample. The semantic encoder is the first 18 layers of the Transformer block of the LLaMA-3 8B backbone decoder with frozen weights. The output hidden state is linearly projected to obtain the node feature matrix. The node feature matrix is ​​then fed into the edge prediction head and the type prediction head to generate the abstract syntax tree token and the data flow graph token, respectively. The abstract syntax tree token is represented by a fixed-length 256-vector sequence consisting of triples of node type number, parent node pointer, and child node pointer. The data flow graph token is represented by a fixed-length 256-vector sequence consisting of triples of variable definition-use edge, control dependency edge, and data type edge.

[0021] Steps 2-3: Concatenate the abstract syntax tree token, data flow graph token, and requirement token into a ternary token tensor at the channel dimension. Perform three scaling dot product attention operations through the ternary cross attention calculation module. Each time, use one token as the query and the other two tokens as the key-value pair to generate the compilation success probability, specification compliance probability, and lineage integrity probability. The compilation success probability is a 0-1 floating-point value returned by the compiler container pool, the specification compliance probability is a 0-1 floating-point value returned by the static specification check engine, and the lineage integrity probability is a 0-1 floating-point value returned by the lineage tracing microservice.

[0022] Steps 2-4: The verification agent fuses the compilation success probability, specification compliance probability, and lineage integrity probability into a joint probability using learnable weighted coefficients. These weighted coefficients are obtained by the verification agent during offline training by maximizing the F1-score objective function. The joint probability is written to a shared message queue in real time for reading in step 3.

[0023] Furthermore: Step 3 includes:

[0024] Step 3-1: When the joint probability of compilation success, specification compliance, and lineage integrity is lower than the preset threshold of 0.95, the verification agent immediately starts the negative reward gradient construction submodule. This submodule performs element-wise subtraction of the cosine similarity difference between the abstract syntax tree token and the requirement token at the misaligned node position, the Euclidean distance difference between the data flow graph token and the reduction token at the misaligned edge, and the token-level edit distance difference between the initial code sample and the standard sample, and then concatenates them to form a negative reward gradient tensor with the same dimension as the lightweight adapter weight.

[0025] Step 3-2: Verify that the agent transmits the negative reward gradient tensor through the backpropagation channel with a learning rate of 1×10. -4The data is directly transmitted back to the lightweight adapter that generates the agent. The backpropagation channel is implemented by the PCIe BAR0 memory area shared by the verification agent and the generating agent. The negative reward gradient tensor is written to the LoRA matrix A and LoRA matrix B of the lightweight adapter in a zero-copy manner with FP16 precision to complete the weight update in real time and generate the agent after correction.

[0026] Step 3-3: After correction, the generated agent maps the negative reward gradient tensor back to the token sequence of the initial code sample according to the node position, applies a probability mask to the mapped position, and the mask value is obtained by normalizing the absolute value of the negative reward gradient tensor. The masked token position is forcibly replaced with the candidate token with the second highest probability in the vocabulary during the next round of autoregressive decoding, so as to achieve accurate correction of misaligned positions.

[0027] Furthermore, step 4 includes:

[0028] Step 4-1: The corrected generated agent receives the negative reward gradient tensor. Each element in the negative reward gradient tensor corresponds one-to-one with the token position of the initial code sample. The corrected generated agent marks the positions corresponding to the elements in the negative reward gradient tensor with absolute values ​​greater than zero as misaligned positions and applies binary masks to these misaligned positions. Positions with a mask value of 1 indicate that they need to be replaced, and positions with a mask value of 0 indicate that the original token is retained.

[0029] Step 4-2: After correction, the generated agent performs token-level replacement on the misaligned positions with a mask value of 1. During replacement, guided by the sign direction of the negative reward gradient tensor, the top 5 candidate tokens with the highest cosine similarity to the reduced token in the vocabulary are selected to form a candidate pool. Then, a token is randomly sampled from the candidate pool as the replacement token. After the mask replacement is completed, the corrected token sequence is obtained.

[0030] Step 4-3: After correction, the generated agent re-inputs the correction token sequence into the heterogeneous decoding stack and re-decodes the supplementary code sample through one forward propagation. The supplementary code sample is a plain text string encoded in UTF-8, with the lineage token's hexadecimal representation appended to its beginning and end.

[0031] Step 4-4: After correction, the generated agent reads the traceability identifier recorded in the lineage token. The traceability identifier is a 256-bit binary vector. The supplementary code sample and the initial code sample are concatenated byte-by-byte according to the traceability identifier. During the concatenation, an incremental lineage chain marker is inserted at the boundary between the two. The incremental lineage chain marker is formed by XORing the SHA-1 hash value of the supplementary code sample and the SHA-1 hash value of the initial code sample and then encoding them with Base64, thus forming a merged code sample with an incremental lineage chain.

[0032] Furthermore: Step 5 includes:

[0033] Step 5-1: The verification agent executes the parallel verification pipeline again on the merged code sample to obtain new compilation success probability, specification compliance probability, and lineage integrity probability. The new compilation success probability, specification compliance probability, and lineage integrity probability are then multiplied element-wise by the learnable weighted coefficients and summed to obtain a new joint probability.

[0034] Step 5-2: The verification agent compares the new joint probability with the preset threshold of 0.95. If the new joint probability is greater than or equal to the preset threshold of 0.95, the verification agent immediately outputs the merged code sample as is and skips the subsequent loop.

[0035] Step 5-3: If the new joint probability is less than the preset threshold of 0.95, the verification agent marks the merged code sample as a secondary initial code sample. The text content of the secondary initial code sample is completely consistent with the merged code sample. At the same time, the verification agent increments the iteration counter of the secondary initial code sample by 1. Before the iteration counter reaches the upper limit of 100 times, the secondary initial code sample is re-injected into the parallel verification pipeline described in step 2, and steps 2 to 4 are executed in a loop.

[0036] Step 5-4: When the iteration counter reaches the upper limit of 100 times or the new joint probability in a certain loop is greater than or equal to the preset threshold of 0.95 for the first time, the verification agent terminates the loop and officially names the currently held merged code sample or secondary initial code sample as the final code sample. The final code sample is a UTF-8 encoded plain text string with a complete lineage token hexadecimal representation appended to its beginning and end, which is used for encapsulating subsequent quadruplet training samples.

[0037] Furthermore: Step 6 includes:

[0038] Step 6-1: Sequentially encapsulate the final code sample and its requirement token, specification token, and complete lineage token, which remain unchanged throughout the process from Step 1 to Step 5, into a quadruple training sample. The quadruple training sample includes the requirement token, specification token, final code sample, and lineage token. Each part is arranged continuously in memory and has a fixed length of 768 dimensions, 1024 dimensions, 512 bytes, and 256 bits, respectively. A 16-byte length identifier is inserted between the four parts to support fast offset addressing.

[0039] Step 6-2: Perform integrity verification on the quadruple training sample. The verification method is to first calculate the SHA-1 hash value of the final code sample, and then compare it bit by bit with the 160-bit hash value embedded in the lineage token. If the comparison results are consistent, the quadruple training sample is determined to be complete. If they are inconsistent, it is discarded and the process is reversed to step 5 to obtain the final code sample again.

[0040] Step 6-3: Write the quadruple training samples that have passed the integrity check into the data pool for large model training in the form of a memory-mapped file. The data pool is a pre-allocated 100GB incremental memory-mapped file. When writing, a sequential append strategy is adopted. The writing address is determined by the 32-bit timestamp in the lineage token to ensure that the quadruple training samples are stored continuously in time order in the data pool.

[0041] Step 6-4: After the data pool is written, trigger the asynchronous index building thread. This thread uses the demand token as the key and the offset address of the four-tuple training sample in the data pool as the value to build an inverted index based on Faiss-IVF1024, which is used for fast sampling when performing full fine-tuning on the generated agent backbone decoder.

[0042] The technological advancements achieved by this invention compared to existing technologies are as follows:

[0043] This invention utilizes a parallel verification pipeline to simultaneously assess compilation results, specification compliance, and lineage integrity. This enables real-time quality screening of generated samples and allows for immediate correction of the generating agent based on negative reward gradient feedback, significantly improving sample correctness and consistency. When sample quality is substandard, the verification agent can drive the generating agent to automatically replace and re-decode locally misaligned locations, forming a continuous, adaptive optimization loop. This enhances the automation of the training data production process and reduces manual intervention.

[0044] This invention uses lineage tokens to record the source and change path of samples during generation, correction, and supplementation, enabling the final samples to have verifiable traceability information. This improves upon the problems of untraceable training sample origins and untrackable modification history in existing technologies. Quadruple training samples are written sequentially to a memory-mapped data pool in a unified format, and a Faiss-IVF1024 inverted index is built based on demand tokens, allowing for rapid, on-demand sample retrieval during subsequent training phases, improving the efficiency of large-scale data management and access. The entire process of sample generation, verification, correction, packaging, and writing is automatically executed by dual agents, significantly reducing manual review, lowering data preparation costs, and enhancing the large-scale production capacity of training data.

[0045] In summary, this invention can generate code training data that is of controllable quality, has a uniform structure, traceable lineage, and is easy to call efficiently without relying on a large amount of manual verification, providing a stable and reliable data foundation for further full-scale fine-tuning of large models. Attached Figure Description

[0046] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0047] In the attached diagram:

[0048] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0049] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0050] like Figure 1 As shown, this invention discloses a dual-agent collaborative code generation data method for training large models, including:

[0051] Step 1: Input the composite cue vector containing demand token, specification token and lineage token into the generating agent. The generating agent outputs the candidate code token sequence autoregressively through a heterogeneous decoding stack composed of a backbone decoder with frozen weights and an adapter connected in series, forming the initial code sample.

[0052] Step 2: Inject the initial code sample into the parallel verification pipeline driven by the verification agent. The verification agent calls the semantic encoder, which shares weights with the generating agent, to extract the graph structure of the initial code sample to obtain the abstract syntax tree token and the data flow graph token. The abstract syntax tree token, the data flow graph token, and the requirement token are then subjected to ternary cross-attention calculation to generate the compilation success probability, specification compliance probability, and lineage integrity probability in real time.

[0053] Step 3: When the joint probability of compilation success, specification compliance, and lineage integrity is lower than a preset threshold, the verification agent encodes the misalignment of the abstract syntax tree token, data flow graph token, and initial code sample into a negative reward gradient, and backpropagates the negative reward gradient to the adapter of the generating agent through the backpropagation channel to achieve real-time weight updates. After correction, the agent is generated.

[0054] Step 4: After correction, the generated agent replaces the misaligned positions of the initial code sample with a mask according to the negative reward gradient, re-decodes the supplementary code sample, and splices the supplementary code sample with the initial code sample according to the tracing identifier recorded in the lineage token to form a merged code sample with an incremental lineage chain.

[0055] Step 5: The verification agent executes the parallel verification pipeline again on the merged code sample. If the joint probability reaches the preset threshold, the merged code sample is output. If it still does not reach the threshold, the merged code sample is marked as the secondary initial code sample and steps 2 to 4 are executed repeatedly until the joint probability reaches the preset threshold or the number of iterations reaches the upper limit, and the final code sample is obtained.

[0056] Step 6: Encapsulate the final code sample and its corresponding requirement token, specification token and complete lineage token into a four-tuple training sample, and write it into the data pool for training large models, for subsequent full fine-tuning of the generative agent backbone decoder.

[0057] Specifically, step 1 includes:

[0058] This step clarifies how, without human intervention, the three types of tokens (requirement token, specification token, and lineage token) are combined into a composite cue vector, and then autoregressive decoding is performed through a heterogeneous decoding stack consisting of a backbone decoder with frozen weights and a finely tuned lightweight adapter. The final output is an initial code sample that can be directly fed into the parallel verification pipeline.

[0059] 1. Input Representation: Construction of Composite Cue Vectors

[0060] 1.1 Formal Representation of Three Types of Tokens

[0061] Demand token: Fixed-length vector It is obtained by concatenating the natural language description of the function, the list of input / output tensor shapes, and industry-standard identifiers, and then performing linear projection.

[0062] Specification token: a fixed-length vector The reduced token is obtained by concatenating the abstract syntax tree node type sequence, the data flow graph edge type sequence, and the security criticality level marker, followed by linear projection. To ensure compatibility with subsequent decoders, the reduced token is dimensionality-reduced to 768 dimensions before concatenation.

[0063]

[0064] in, For a fixed (offline training / design) linear mapping matrix, This is the bias vector.

[0065] Lineage Token: Binary Vector (160-bit SHA-1 + 32-bit timestamp + 16-bit license number), first obtained through bit-level to real-value hash embedding mapping. :

[0066]

[0067] in, It is a fixed hash-projection function (which can be a combination of several lookup tables and linear projections).

[0068] 1.2 Learnable Separate Embeddings and Composite Cue Tensors

[0069] To preserve the boundary information of each token and provide positional context for the decoder, learnable separator embeddings are inserted between the three vectors. The construction steps are as follows:

[0070] Will , , Column-wise concatenation, with a delimiter embedded at the concatenation point, yields the sequence:

[0071]

[0072] The final composite hint vector is obtained by performing column projection or aggregation at the interface. (For example, through pairwise merging or summary projection), here a piecewise average pooling approach is used:

[0073]

[0074] in, For a learnable weighted average projection, the final shape is ,Should That is, it serves as the input of the composite cue vector for generating the intelligent agent.

[0075] The above design of dimensionality reduction / projection and partitioning embedding ensures that the strong representational information of the reduction token and lineage token is preserved, while making the input dimension consistent with the generated backbone (768-dimensional hidden layer), which facilitates direct interaction with the frozen backbone.

[0076] 2. Generating Intelligent Agents: Heterogeneous Decoding Stack Structure

[0077] 2.1 Overall Architecture (Heterogeneous Decoding Stack)

[0078] The generated agent consists of two parts connected in series:

[0079] The frozen weights backbone decoder is specified as an LLaMA-3 8B decoder backbone (all backbone parameters are not trainable at this stage). This backbone has hidden dimensions. Number of floors .

[0080] A finely tuned, low-rank adapter containing only 0.1% of the trainable parameters used to generate the backbone. The low-rank adapter injects parameters into the backbone's Query and Value projection layers using LoRA format. The LoRA matrix has a rank of [value missing]. The specific injection method is as follows:

[0081] For any trunk projection (Query / Value), using LoRA bypass:

[0082]

[0083] in, , For trainable matrices, This is the scaling factor. Only. , To be trainable, its parameters account for approximately 0.1% of the backbone parameters.

[0084] 2.2 Parameter Freezing and Partitioning of Trainable Subspace

[0085] All weights of the backbone decoder are frozen (untrainable) to provide stable language and code generation priors;

[0086] The Lightweight Adapter (LoRA) parameter is set to the only trainable subspace in this stage. Subsequent steps (verification backpropagation) will write the gradient into this subspace to achieve real-time updates.

[0087] This heterogeneity ensures that large-scale representation capabilities are handled by the backbone, while online / incremental improvements are accomplished by the adapter at high frequency and low cost, thus meeting the needs of training-inference collaboration.

[0088] 3. Autoregressive Decoding and Temperature Annealing Sampling Strategy

[0089] 3.1 Autoregressive Generation Process (Tensor Level)

[0090] make Given a composite cue vector, an adapter-injected heterogeneous decoding stack performs autoregressive inference: at time step Output token probability distribution The backbone decoder performs the following during forward propagation: Perform cross-attention, treating it as a conditional context.

[0091] 3.2 Temperature annealing sampling (0.8→0.2 linear annealing)

[0092] To strike a balance between diversity and compilation pass rate, a linear annealing temperature is adopted. Depending on the generation location The strategy of change, from the entire autoregressive generative process Linear annealing to Formalized as:

[0093]

[0094] in, To determine the maximum token length for output, at each step, the model's... The probability is obtained by applying softmax after temperature scaling:

[0095]

[0096] Sampling employs a combination of Top-k / Top-p cropping and temperature-based sampling to balance long tails and accuracy.

[0097] 3.3 Sampling and Decoding Details

[0098] exist First, perform temperature scaling and truncation on logits, then sample to obtain... .

[0099] If a special termination condition is encountered (such as encountering a terminator or reaching a certain threshold) (The generation process stops).

[0100] Sampling rules and annealing maintain high diversity in the sequence at the initial position (high temperature) and converge to more conservative candidates in the later stage (low temperature), thereby improving the overall syntactic / compilation reliability while maintaining semantic diversity.

[0101] 4. From candidate token sequence to initial code sample (post-processing)

[0102] 4.1 Vocabulary Inverse Mapping and Whitespace Recovery

[0103] The generated candidate code token sequence has a maximum length of 512. After reverse mapping of the vocabulary (token → string) and restoration of whitespace, indentation, and line breaks (based on predefined reverse normalization rules), a draft of the code text is formed. .

[0104] 4.2 Lineage Token Attachment and Uncompilable Comment Format

[0105] To facilitate rapid tracing and unalterable pedigree records in subsequent verification phases, The beginning and end of the string are appended with the hexadecimal representation of the lineage token as uncompileable comments, formally represented as:

[0106]

[0107] in, , This involves wrapping comments that are recognizable in the target language, but with the semantic markup of "uncompileable comments" (meaning the impact of these comments on compilation should be ignored during the verification phase). The final result is the initial code sample, a plain text string encoded in UTF-8, with a lineage token hexadecimal representation appended to both ends, used for source tracing in the parallel verification pipeline.

[0108] Specifically, step 2 includes:

[0109] Based on the initial code sample generated by the generating agent, this step involves the verification agent injecting the sample into the parallel verification pipeline and calling the semantic encoder, which shares weights with the generating agent, to extract the graph structure (AST, DFG) of the code. Subsequently, the abstract syntax tree token, data flow graph token, and requirement token are interactively reasoned using ternary cross attention, and finally three types of probabilities are generated in real time: compilation success probability, specification compliance probability, and lineage integrity probability.

[0110] 2-1 Parallel Verification Pipeline Overall and Zero-Copy Transfer Contract

[0111] Three types of verification tasks (compilation, static specification check, and lineage tracing) are completed in parallel with latency targets ranging from milliseconds to hundreds of milliseconds. The 0-1 floating-point probabilities of each task are quickly returned to the verification agent for use in ternary cross-attention and subsequent fusion.

[0112] Parallel process composition (3 processes):

[0113] Compiler container pool: A dynamic pool of language / target-specific containers (e.g., gcc / clang, rustc, stc, CUDAtoolchain, etc.) used to attempt actual compilation / linking / static building. Output: Compilation return code, compilation log summary (for subsequent error mode mapping).

[0114] Static specification check engine: a collection of multiple rule engines (rule sources: MISRA / C, CERT, IEC-61131-3 specification fragments, etc.), which checks the satisfaction of a set of rules based on AST / DFG and generates a specification compliance score (0-1).

[0115] The pedigree tracing microservice verifies the consistency of the pedigree tokens (hex(h)) attached to the beginning and end of the initial code sample, compares the sample pedigree identifier with the data pool / index, and returns the pedigree integrity probability (0-1).

[0116] Shared Channel and Zero-Copy: The three processes interact with a pre-established shared memory region through the same POSIX message queue (used for scheduling and metadata). The initial code sample is written to the shared memory as a memory image (UTF-8 bytes) by the generated agent, and metadata (offset, length, blood_hex, prompt_id, seed) is placed in the message queue. The verification process directly reads the image of this memory region using a zero-copy method, avoiding copy latency and GC pressure, thus meeting the requirements of high-throughput scenarios.

[0117] Contractual terms: Provided in shared memory are (1) the initial code sample byte range, (2) the lineage token hexadecimal (hex(h)), (3) the composite hint vector ID, and (4) the sampled metadata (temperature curve, seed). The verification process includes a consistent signature (e.g., hash digest) when reporting probabilities for subsequent lineage checks.

[0118] 2-2 Semantic Encoder: From Code Text to Graph Structure Tokens

[0119] The semantic encoder that verifies the agent's invocation and generation of agent weights is shared to ensure the consistency of the representation space. This semantic encoder is specified as a forward subnet of the first 18 Transformer blocks (frozen weights) of the LLaMA-38B backbone decoder, with the aim of sharing the same semantic foundation and reusing the backbone's code / language representation capabilities.

[0120] Processing flow:

[0121] 1. Input: Initial code sample (token sequence generated after inverse mapping of the vocabulary) Note: The first and last lineage annotations are ignored or parsed separately during the verification phase and do not affect AST / DFG parsing.

[0122] 2. First 18 layers forward: Semantic encoder pairs Perform the forward operation to obtain the hidden state tensor:

[0123]

[0124] in, The implicit representation vector corresponding to the token has its core weights frozen to ensure that it shares the same representation benchmark as the generation side.

[0125] 3. Node feature matrix construction: [This section appears to be incomplete and requires further context.] Applying linear projection (This can be a small-scale MLP) Obtain the node feature matrix:

[0126]

[0127] in, The number of candidate syntax nodes inferred (determined by the parser / prediction head). For node feature dimensions (here) (To match the fixed-length 256 vector specification).

[0128] 4. Edge prediction head and type prediction head: node features Two types of prediction heads are sent respectively:

[0129] Edge prediction head: Predicts whether there are DFG / control-dependent edges between nodes and the edge type, outputting the edge set and edge type probability matrix;

[0130] Type prediction header: Predicts the node type number, parent pointer, child pointer or other structured attributes for each node, and outputs a node type vector.

[0131] The outputs at both ends are serialized and padded with fixed length to obtain:

[0132] Abstract Syntax Tree Tokens (AST Tokens): Sequences each The vector encoding includes an embedded representation of node type number and parent / child pointer information.

[0133] Data Flow Graph Token (DFG Token): Sequence each Vector-encoded variable definition - an embedded representation using information such as edges, control dependency edges, and data type edges.

[0134] Candidate number of nodes and edges , An upper bound padding strategy is employed to form a fixed-length sequence (padding + mask), facilitating downstream tensor quantization operations and parallel computation with the GPU. Untested node positions are marked with a zero vector and a mask.

[0135] 2-3 Ternary Cross-Attention Calculation Module (Generates Three Types of Original Probabilities)

[0136] Input tensor:

[0137] AST token sequence ;

[0138] DFG token sequence ;

[0139] Request token (From step 1; if dimension alignment is required, first map to 256 dimensions using linear projection:) ).

[0140] To facilitate ternary attention calculation, the three types of tokens are concatenated into a ternary token tensor along the channel dimension:

[0141]

[0142] Triple scaling dot product attention: The module performs three attention operations, selecting one token set as the query and the remaining two as the key-value pairs in each operation. A typical scaling dot product attention is denoted as:

[0143]

[0144] Specifically, three operations:

[0145] 1. —Using the AST as the query, measure the AST's response to DFG+ requirements and generate an attention representation. .

[0146] 2. —Using DFG as the query, the output is... .

[0147] 3. —Using the demand token as the query, the output is... .

[0148] Each attention output Pooling (e.g., global averaging or learnable aggregation) in a dimension yields a scalar or small-dimensional vector, which is then mapped to the original probability prediction. Specifically, the mapping is as follows:

[0149] Compilation passed the original score (from) (with the compiler container's return): Predictions within the model Mapped via sigmoid:

[0150]

[0151] Actual final compilation success rate The 0-1 floating-point value returned in real time by the compiler container pool is used as the standard (prioritizing the actual compilation result outside the compiler); the verification system will integrate the two.

[0152] The specification conforms to the original score (from) (Returns from the static specification check engine)

[0153]

[0154] The static specification checking engine returns the true rule satisfaction level (0-1) as a reliable external signal.

[0155] Bloodline integrity original score (from) (and pedigree tracing services):

[0156]

[0157] The credibility of the 0-1 floating-point value returned by the lineage tracing microservice (whether it matches the index / data pool) is also used as an external signal.

[0158] In actual operation, such as when the compiler container returns the true compilation probability... The static engine returns Bloodline service return The verification agent can view these as "observation signals," while the internal prediction generated by the ternary cross attention... It is then used as a reference for confidence estimation, anomaly detection (difference between model prediction and real signal), and subsequent construction of negative reward gradients.

[0159] Learnable weighted fusion of 2-4 joint probabilities and offline training

[0160] The validator fuses the three types of probabilities into a joint probability using learnable weighted coefficients. To ensure that the coefficients are non-negative and comparable, the weight vectors are standardized using softmax. Obtain weights :

[0161]

[0162] The joint probability is defined as a weighted linear combination:

[0163]

[0164] in, Real-time return values ​​from compiler containers, static specification engines, and lineage services; model-internal predictions when external signals are missing. Replacement or a weighted combination of both.

[0165] Offline Training and F1 Maximization: Weight Parameters The training is conducted offline, with the training objective being to maximize the task-level F1 score (or equivalent Fβ) on the labeled validation set. Directly maximizing F1 is a non-continuous objective, and in practice, one of the following strategies is adopted:

[0166] Alternative differentiable objectives: Training uses continuous approximations (e.g., a differentiable surrogate for F1, or optimizing the cross-entropy of binary classification and searching for the maximum F1 score).

[0167] Two-stage optimization: First, optimize the weights using cross-entropy / log loss to obtain a good probability estimate, and then perform threshold tuning on the validation set to maximize F1.

[0168] If we use cross-entropy (CE) differential training, the objective is to minimize:

[0169]

[0170] Subsequently, through search or fine-tuning based on the validation set, Maximize. Fix after training. And at runtime, only read the vector to compute. .

[0171] Real-time writing to the message queue: The verification agent will calculate the value for each initial code sample. , , And merged into Then, the scalar value is transferred in real time. The original ternary probabilities, the pedigree ID / offset of the corresponding sample, and the timestamp are written back to a shared POSIX message queue for the negative reward gradient constructor in step 3 to read. The message also contains the fusion weights. The current snapshot and confidence level (such as historical average) are used for subsequent diagnosis and traceability.

[0172] Specifically, step 3 includes:

[0173] The logic of step 3 is that, having obtained the initial code sample, AST / DFG token, demand token, and joint probability obtained by fusing ternary cross-attention with the external verification process in steps 1-2, .when At that time, the verification agent immediately starts the negative reward gradient construction → backpropagation → generating agent for real-time update → the next round of correction and generation of a fast closed loop.

[0174] 3-1: Construction of negative reward gradient (the gradient tensor dimension must be exactly the same as the lightweight adapter)

[0175] From steps 2-4, we can obtain:

[0176]

[0177] when

[0178]

[0179] The verification agent immediately starts the negative reward gradient construction submodule.

[0180] (1) AST tokens and demand tokens: cosine similarity difference of misaligned nodes

[0181] For nodes in the AST that are identified as misaligned by the ternary cross attention (using the mask provided by module 2), take the node vector. With demand token vector Calculate cosine similarity:

[0182]

[0183] This is the penalty for a mismatch between the grammatical structure and the requirements.

[0184] (2) DFG token and reduction token: Euclidean distance difference of misaligned edges

[0185] For the ternary relation vectors marked as misaligned edges in the DFG With the specification token (the specification vector returned by the static specification checking engine) ):

[0186]

[0187] Used to measure the degree to which variable flows and control dependencies deviate from the norm.

[0188] (3) Initial code sample vs. standard sample: Token-level edit distance difference

[0189] Perform Levenshtein distance normalization on the initial code token sequence generated in step 1 and the standard samples (from the internal specification library or the "closest template" returned by the static analysis engine):

[0190]

[0191] in, The sequence length is guaranteed to be normalized to the range of 0-1.

[0192] The three types of differences mentioned above form three tensors (after masking and padding in step 2), which are then used to verify that the agent performs element-wise subtraction and concatenates the results:

[0193]

[0194] Then, a linear transformation / reshape is performed to make the tensor dimension completely consistent with the LoRA adapter weights (matrices A and B) of the generated agent:

[0195]

[0196] at this time This is the negative reward gradient tensor, whose shape strictly matches the dimensions of the A and B matrices of LoRA.

[0197] 3-2: Instantly update the lightweight adapter (LoRA) via the reverse propagation channel

[0198] Backpropagation channel (PCIeBAR0 zero-copy)

[0199] Step 2 has committed to verifying that the agent and the generating agent share a PCIe BAR0 mapping area.

[0200] Negative reward gradient tensor (FP16) Writes directly to BAR0 in zero-copy mode without going through the CPU buffer, which greatly reduces latency.

[0201] Update rules (learning rate fixed at 1×10) -4 )

[0202] LoRA weight update:

[0203]

[0204]

[0205] in, , From The pieces are mapped to the corresponding parts of the A and B matrices of LoRA.

[0206] Because the backbone Transformer (such as the LLaMA-3 8B backbone) has frozen weights, the only updates are to the LoRAA and B of the lightweight adapter, so real-time corrections can be completed within tens of milliseconds.

[0207] 3-3: The corrected generated agent forces the replacement of misaligned positions (second highest probability token replacement strategy).

[0208] After the weights are updated, the generated agent needs to immediately perform point corrections on the next round of decoding.

[0209] The process is as follows:

[0210] (1) Map the negative reward gradient back to the code token sequence

[0211] Verify the agent will Combined with the AST / DFG node location mapping table extracted in step 2, the gradient term mapped to the original token sequence is obtained:

[0212]

[0213] (2) Construct a probability mask.

[0214] Normalize the gradient of each token by taking its absolute value:

[0215]

[0216] make This indicates the strength at which the position needs to be replaced.

[0217] (3) Force replacement with the token with the second highest probability in the vocabulary.

[0218] In the next round of autoregressive generation (a recall of step 1), for each position :

[0219] like In this case, the current top-1 token is masked in the softmax output distribution, and the top-2 token is forced to be selected:

[0220]

[0221] This mechanism ensures that:

[0222] Only the misaligned position was modified;

[0223] The modification range is controllable (not random sampling, but top-2 precise replacement);

[0224] By aligning the location of the structural error with the output of step 2, the controllability and repairability of the sample are improved.

[0225] Specifically, step 4 includes:

[0226] Input (from the output of step 3):

[0227] Initial code sample UTF-8 text, with uncompileable comments beginning and ending with the lineage token hex(h);

[0228] AST token sequence With DFG token sequence (A fixed-length 256-vector sequence, including a mask);

[0229] Request token Convention token (All have been mapped to 256 / 768 dimensions);

[0230] Negative reward gradient tensor (From step 3, after reshaping and sharding, each element corresponds one-to-one with a token position or AST / DFG node / edge in the initial code sample).

[0231] Its goal is to use Identify and correct misplaced tokens, and generate supplementary code samples. and put and A sample merged code is created by piecing together the traceability identifiers from the lineage tokens. (with incremental pedigree) for further verification and reuse in step 5.

[0232] 4-1: Misalignment Detection and Binary Mask Application

[0233] Mapping rule: Verify that the agent maintains a mapping table. (Generated from the AST / DFG→token index mapping in step 2), and its definition is:

[0234]

[0235] Each of them The element corresponds to the position in the initial token sequence. (The same position can be mapped to by multiple structural elements, using a strategy of accumulation or taking the maximum absolute value).

[0236] Misalignment detection and binary masking:

[0237] For each token position Take the maximum absolute value of all gradient elements mapped to that position:

[0238]

[0239] in, For mapping to location Apply a binary mask to the set of indices:

[0240]

[0241] Mask vector (with initial token length) (One-to-one correspondence), the position with a mask value of 1 is marked as the position that needs to be replaced (misaligned position).

[0242] Additional strategy: To avoid noise substitution caused by extremely small gradients, a threshold can be introduced. , changed to If and only if Threshold Set as system hyperparameters or adaptively based on sample confidence levels.

[0243] 4-2: Token-level replacement – ​​candidate pool construction and randomization selection

[0244] Replacement of directional guidance (utilization of symbolic information):

[0245] The sign of the negative reward gradient Indicates directional deviations (e.g., a plus sign might indicate "missing structure / identifier," while a minus sign indicates "violation / redundancy"). This symbol is used when constructing the candidate pool to prioritize matching with specification tokens. The semantically closest candidate subset (that satisfies the reduction).

[0246] Candidate pool construction steps (for each position to be replaced) ):

[0247] 1. Contextual information: Get the current position Local context vector It is obtained by splicing the implicit representations within the forward / backward window or by mapping the node features in step 2.

[0248] 2. Lexicon Embedding Retrieval: The set of embedding vectors for all tokens in the lexicon. (Pre-compute and index) Computation and specification tokens cosine similarity (or with) and (linear combination)

[0249]

[0250] 3. Top-5 selection: Selection and... The set of the top 5 token indices with the highest cosine similarity:

[0251]

[0252] If the direction of the symbol needs to be biased towards "insertion / deletion / replacement", symbol information can be weighted in the similarity ranking (e.g., by...). and Make directional adjustments.

[0253] 4. Random sampling: from the candidate pool China uses a predetermined random strategy to sample a token as a replacement token. Sampling can be performed using a uniform distribution or a similarity-weighted distribution (e.g., softmax over sim).

[0254] The corrected token sequence is obtained after replacement:

[0255]

[0256] Obtain the modified token sequence .

[0257] Repeatability and random seed: The replacement process records a snapshot of the random seed and the candidate pool sorting to ensure traceability and reproducibility (meeting pedigree audit requirements).

[0258] 4-3: Re-decode the supplementary code sample (one forward propagation)

[0259] Input: Correction token sequence (Or convert it into a composite cue + mask context and enter it into the autoregressive process, either option is acceptable), and the original composite cue vector. (Including demand tokens, convention tokens, and lineage tokens).

[0260] Processing: Inject the correction token sequence or correction hint into the heterogeneous decoding stack (see step 1: freeze the backbone + LoRA adapter), perform one forward propagation, and autoregressive / parallel decoding to generate supplementary code samples. Post-processing is the same as step 1: vocabulary demapping, whitespace / indentation restoration, and appending the hexadecimal representation of the lineage token (non-compilable comments) at the beginning and end.

[0261] Output characteristics:

[0262] Encode plain text strings in UTF-8;

[0263] The hexadecimal pedigree notes appended at the beginning and end should be consistent with Consistency (temporarily the same lineage token hex(h)) is required to identify the original traceability identifier during the assembly stage;

[0264] During decoding, the temperature curve, top-k information, random seed, and metadata of the replaced position are recorded and written to the sample metadata database for auditing.

[0265] 4-4: Byte-level concatenation and the generation of incremental lineage chains

[0266] Definition of pedigree markers (reiterated):

[0267] Original Bloodline Token It is a 256-bit binary vector (160-bit SHA-1 hash + 32-bit timestamp + 16-bit license number), and its hexadecimal representation is... Appended to the beginning and end of the text, this is a byte-level concatenation, which requires operation on the actual byte stream (UTF-8 encoding).

[0268] SHA-1 hashing and incremental lineage chain construction:

[0269] 1. Standardize both the initial code sample and the supplementary code sample (after removing uncompileable comments at the beginning and end or maintaining a consistent processing strategy) and calculate their SHA-1 hash values ​​(160 bits):

[0270]

[0271] in, This represents the normalized byte stream used for lineage operations (e.g., the same normalization process that removes the timestamp-differentiated annotation shell to ensure consistency).

[0272] 2. Calculate the bitwise XOR and Base64 encode it as the incremental pedigree chain marker:

[0273]

[0274]

[0275] in, A 160-bit binary vector; Base64 encoded This is a printable string, making it easy to embed comments.

[0276] Byte-level concatenation strategy:

[0277] Perform byte-level sequential concatenation on the original byte streams of the two samples (keeping them UTF-8), that is:

[0278]

[0279] in, The inserted segment is a structured segment containing incremental lineage markers and necessary metadata (such as timestamps and replacement location summaries).

[0280] When concatenating, adhere to the language comment syntax to ensure that the concatenated code can still be ignored during compilation (or that boundary comments are removed as needed during the verification phase before compilation), while maintaining searchability in terms of data lineage.

[0281] Final merged code sample:

[0282] Convert the byte-level concatenation result to UTF-8 text representation, ensuring that both ends retain their original complete lineage token hexadecimal representation (i.e., And, at the intersection of the two, an incremental lineage chain marker is inserted (as shown above). This results in the final merged code sample. (UTF-8 text), which contains the following machine-readable fields:

[0283] Original lineage token hex(h) (head / tail);

[0284] Incremental pedigree tag (inc_tag);

[0285] Replace the location digest (location array or bit vector);

[0286] Timestamp and random seed (used for reproducing replacement).

[0287] Integrity verification (before data storage):

[0288] calculate SHA-1 and included in the construction , And perform consistency checks on inc_tag (such as verification) If the verification fails, the merged sample is rejected and a rollback or retry process is triggered.

[0289] Specifically, step 5 includes:

[0290] Merged code sample : Generated from step 4, containing initial code samples Supplementary code samples The first and last complete lineage tokens hex(h), and the incremental lineage chain marker inc_tag at the boundary and the replacement position digest.

[0291] Mapping table Maintain an invertible mapping from LoRA gradient indices / AST / DFG elements to code token locations.

[0292] Preset threshold: (Configurable), serving as a threshold for joint probability qualification.

[0293] Maximum number of iterations: .

[0294] Learnable weighted coefficients: The determination and fixation are made during the offline phase (see steps 2-4).

[0295] 5-1: Parallel verification of merged code samples and calculation of new joint probabilities

[0296] Parallel verification call: Inject the parallel verification pipeline (compiler container pool, static specification checking engine, pedigree tracing microservice) defined in step 2 to obtain three types of real-time observation probabilities in parallel:

[0297] —Compilation success probability (from compiler container pool);

[0298] —Probability of specification compliance (from the static specification check engine);

[0299] —Probability of intact lineage (from the lineage tracing microservice).

[0300] Joint probability calculation formula (same weights as in steps 2-4):

[0301]

[0302] in, The weight vectors are pre-trained and fixed, and .

[0303] Real-time write-back: Verify that the agent will ( , , , )and The lineage ID, timestamp, and verification run ID are written back to the shared message queue and added to the audit log (including a log summary of the verification engine for traceability).

[0304] 5-2: Threshold Comparison and Output Decision

[0305] like

[0306]

[0307] Then output immediately (as is) As a qualified sample, skip subsequent loops; and mark status=ACCEPTED in the output record. `iteration=k` (current iteration number, initial k can be 0 or 1, depending on the implementation). This sample will then proceed to step 6, the quadruplet encapsulation process.

[0308] like

[0309]

[0310] Then proceed to step 5-3. Marked as secondary initialization code sample And enter the loop control.

[0311] 5-3: Control logic and counter management for cyclic execution (re-injection steps 2-4)

[0312] Iteration counter: Maintain iter_count (initial value 0) for each sample. When When deemed unqualified:

[0313] 1. Change iter_count ← iter_count + 1.

[0314] 2. If iter_count < Then the secondary initial code sample Re-inject the parallel verification pipeline from step 2, and repeat the process from step 2 to step 3 to step 4 to step 5. During re-injection, the following invariants must be preserved and passed (for traceability and reproducibility):

[0315] Bloodline token hex(h);

[0316] Complete replacement history (all incremental pedigree marker sequences);

[0317] Random seed log;

[0318] Historical joint probability sequence .

[0319] 3. If iter_count ≥ The loop terminates (see 5-4).

[0320] For multiple samples in the concurrent processing queue, based on iter_count and the most recent... Prioritize data based on factors such as code complexity (e.g., number of AST nodes), prioritizing high-potential samples to improve overall output. Under high load or repeated non-convergence conditions, the system may allow short-term relaxation of thresholds (e.g., under operational strategies) This only applies to specific low-risk categories, but must be fully recorded in the compliance log and auditable evidence must be retained. This is a configurable strategy and does not affect the core patent process. To avoid the system falling into self-replication and excessive local convergence, the original candidate is retained with a certain probability (based on sampling temperature or replacement randomness) even after multiple iterations of the same initial prompt, in order to maintain the diversity of the training data boundary.

[0321] 5-4: Termination Conditions, Final Code Sample Naming and Output Encapsulation

[0322] Termination Trigger Condition: When any of the following conditions are met, the verification agent terminates the loop and names the currently held sample as the final code sample. :

[0323] (The threshold is reached for the first time or in a certain cycle); or

[0324] iter_count has reached its limit. (Forced termination).

[0325] Output Sample Specification: Final Code Sample To encode a plain text string in UTF-8, the following requirements must be met:

[0326] 1. Lineage integrity: The beginning and end are accompanied by the complete lineage token hex(h); if multi-level incremental lineage chains are generated during the loop, the complete incremental lineage chain sequence (e.g., inc_tag_1, inc_tag_2,...) is preserved in the sample annotation area.

[0327] 2. Verification Evidence: Includes complete verification metadata, including the three probability sequences for each verification and the weight vector used. This includes a summary of each compilation log, a summary of replacement locations, a random seed, and LoRA update snapshots (time series). This metadata is embedded in sample annotations as structured meta-blocks or written to parallel audit storage to meet traceable auditing requirements.

[0328] 3. Termination flag: The sample's status field final_status (ACCEPTED or FORCED_ACCEPTED if it reaches...) The values ​​of `final_Pjoint` and `iter_count` are written to the data pool directory records.

[0329] Perform eventual consistency checks before the final output:

[0330] Calculate the SHA-1 of the normalized version of the sample. ;

[0331] Verify the consistency of the incremental lineage chain (if there are multiple levels of incremental chains, check that each level's Base64(H_i\oplusH_{i-1}) equals the recorded inc_tag_i).

[0332] If the verification fails, the sample is marked with the CORRUPT flag and a rollback is triggered.

[0333] Additional strategies: failure handling, rollback, and manual review trigger points.

[0334] Non-convergent pool: For samples that reach and For samples that are not specified, the system marks them as NON_CONVERGENT and processes them according to the policy:

[0335] Write the data to the isolated data pool and label it with its risk level;

[0336] Trigger manual review or more powerful fixers (such as deeper model or specific rule replacers) as needed—this process is non-automatic and optional.

[0337] Detailed logs are maintained for each failed round (compiler error summary, static check failures, lineage inconsistency details) for model improvement or rule reduction enhancement. If a single sample cycle consumes abnormally high resources (long-term container / CPU occupation), graceful degradation is triggered: the sample is removed from the main pipeline to release resources.

[0338] When the sample becomes (Whether ACCEPTED or FORCED_ACCEPTED), the validating agent encapsulates its own and its complete metadata (requirement token, specification token, final code text, lineage token, verification evidence, LoRA update history) into a "pending pool object" and sends it to the data pool write and quadruple encapsulation process specified in step 6.

[0339] Specifically, step 6 includes:

[0340] 6-1 Memory Layout and Packaging Rules for Quadruple Training Samples

[0341] Logical quadruplets (in order):

[0342] [Requirement Token] → [16-byte Separated Identifier] → [Convention Token] → [16-byte Separated Identifier] → [Final Code Sample] → [16-byte Separated Identifier] → [Lineage Token]

[0343] Each part has a fixed representation and byte length (arranged contiguously in memory):

[0344] Request token: 768 dimensions — using float32 storage (4 bytes per dimension), number of bytes byte;

[0345] Separator identifier: 16 bytes (used for fast offset addressing and segment integrity).

[0346] Protocol token: 1024-dimensional—float32 storage, bytes byte;

[0347] Separator identifier: 16 bytes;

[0348] Final code sample: 512-byte fixed-length text field (UTF-8 encoded, longer fields will be handled according to cropping or fragmentation rules);

[0349] Separator identifier: 16 bytes;

[0350] Lineage token: 256 bits = 32 bytes (160-bit SHA-1 + 32-bit timestamp + 16-bit license number), stored in binary form.

[0351] Number of bytes in a single fixed-length quadruple (record length):

[0352]

[0353] Item-by-item value: 3072+16+4096+16+512+16+32=7760 bytes.

[0354] Fast offset addressing formula (if the sample's index in the data pool is obtained by sorting by timestamp) The starting address of the data pool is ):

[0355]

[0356] This offset facilitates constant-time random access (seek) and address references in the Faiss index.

[0357] Metadata (which does not occupy a fixed area of ​​the record but is written to the audit stream) includes: sampled temperature curves, sampled random seeds, replacement location summaries, verification evidence (joint probability sequences), LoRA update snapshot pointers, etc. These are stored in a compressed / archived manner through external audit logs or side-view files, with each record associated with a delimiter in a quadruple (the delimiter contains an index or pointer to the audit stream).

[0358] 6-2 Integrity Verification (Strong Consistency Check Before Writing)

[0359] Verification steps:

[0360] 1. For the final code sample (the third part of the quadruple), normalize it to... (Consistent with the normalization strategy in step 4) Calculate the SHA-1 hash:

[0361]

[0362] The result is a 160-bit hash (written in binary or hexadecimal representation).

[0363] 2. Read the embedded 160-bit hash from the quaternion's lineage token region. .

[0364] 3. Inspection:

[0365]

[0366] Inconsistency handling:

[0367] If there is a discrepancy, the quadruple is discarded (not written to the data pool) and a rollback is performed: the verification agent is marked RETRY and rolled back to step 5 (reacquire or trigger manual review), while the reason for the discrepancy and the context (last LoRA update snapshot, compilation log fragment, etc.) are recorded in the audit log.

[0368] 6-3 Sequentially append data to an incremental memory-mapped file (100GB pre-allocated).

[0369] The data pool is a single monolithic memory-mapped file (mmap file), with its size pre-allocated at the system level. The file is populated by the writer using a sequential append strategy.

[0370] Write operations employ atomic fetch-and-add to manage the global write pointer `write_ptr` to avoid concurrent write conflicts (i.e., before each write operation, the atomic operation `pos = fetch_and_add(R)` is performed to obtain the starting offset `pos` for this write operation, and then the quadruple is written). +pos).

[0371] Write steps (atomic / transactional):

[0372] 1. After the integrity check passes, execute pos=atomic_fetch_and_add(write_ptr,R) (using atomic instructions or system calls to ensure concurrency safety).

[0373] 2. In +pos writes the byte sequence of the quadruple (direct writing to the memory-mapped region to achieve a zero-copy effect).

[0374] 3. Perform fsync or an equivalent persistence step and write a write-before-write (WAL) record block (for crash recovery).

[0375] 4. After successful writing, push the write event (including pos, lineage token, timestamp, and sample ID) to the message queue and audit stream.

[0376] The write address is determined by the lineage token timestamp order, and one of the following two implementation strategies can be adopted in a concurrent environment:

[0377] Strategy A (Batch Sorting): Collect several quadruplets to be written into a local batch (e.g., 1k records or a time window of 1 second), sort the batch by the 32-bit timestamp in the lineage, and then perform sequential writing (ensuring that the data pool is stored continuously in chronological order). This method is a trade-off between throughput and ordering and is suitable for high concurrency.

[0378] Strategy B (Bitmap Insertion and Delayed Insertion): Directly use atomic append writes to pos (fastest), while maintaining a time-series reordering process at the index layer: asynchronous reorganization threads periodically rewrite / remap the index to the sequential logical view based on the lineage timestamp (append writes are maintained within the physical file, but logical offsets are mapped by the index). This method has the highest write throughput, but the index layer needs to handle the time-series logic.

[0379] To ensure that accepted but not persisted writes are not lost, a Write-Ahead Log (WAL) (including a quadruple header, checksum, and target offset) is written before writing. After a successful write, the WAL is marked as committed and can be cleaned up. During crash recovery, the WAL is used for replay or rollback.

[0380] 6-4 Asynchronous Index Building Thread (Faiss-IVF1024 Inverted Index)

[0381] The goal is to build an efficient inverted index with demand tokens as keys and the offset address of the quadruple in the data pool as values, which can be used to quickly sample training samples semantically or by nearest neighbor before full fine-tuning.

[0382] Preparation of index keys:

[0383] Request token For a 768-dimensional float32 vector (consistent with the storage format in quadruplets), to adapt to Faiss, first perform linear dimensionality reduction or multiplication by OPQ mapping:

[0384]

[0385] Among them, commonly used =128 or 256. Pre-training or random initialization is performed before the index building thread starts, and offline training is optional to improve index accuracy (OPQ / PCA / whitening optional).

[0386] Faiss configuration:

[0387] The main index uses IVF1024 (i.e., 1024 inverted clusters) to improve retrieval throughput and coverage. To reduce memory consumption and improve retrieval speed, Product Quantization (PQ) can be combined: the combination of IVF1024 + PQ64 is commonly used. Index training is performed after the first batch of written samples arrives (cluster centers need to be trained).

[0388] The stored value of an index entry is the offset address of a quadruple (i.e., offset_q), plus sparse metadata such as sample weights / timestamps for subsequent sampling by time or weight.

[0389] Asynchronous index building process:

[0390] 1. After writing is complete, an event (including the demand token r and offset_q) is sent to the indexing thread. The indexing thread then processes r... Map to v and add (v, offset_q) in batches to the index buffer.

[0391] 2. When the buffer reaches the training size or training is triggered periodically, execute Faiss's train (if it's the first time building) and add data in batches using add_with_ids. Use IVF1024 clustering and perform PQ compression on the vectors (to save memory).

[0392] 3. The index remains searchable and periodically takes index snapshots for fault tolerance. These snapshots are written to independent persistent storage for recovery after a restart.

[0393] Index lookup and sampling strategies (to be used for subsequent fine-tuning):

[0394] During full fine-tuning, the sampler retrieves candidate samples from the index using the following strategy:

[0395] Semantic nearest neighbor: given a demand token Search recent The vectors yield the offset set Read the corresponding quadruples and form a batch.

[0396] Time decay sampling: Combine pedigree timestamps to give higher sampling weights to recent samples.

[0397] Diversity / Deduplication: Introduce a cluster balancing strategy in sample selection to avoid excessive repetition of similar samples (a frequency cap can be set for samples from the same source warehouse or with the same lineage).

[0398] Failure rollback: If the Faiss index fails or is not ready, rollback to sequential scan or a simple hash-based sampling strategy to ensure that the fine-tuning process is not interrupted.

[0399] 6-5 Interfacing with the Generative Agent Backbone Decoder for Full Fine-Tuning

[0400] The data pool provides high-quality, compliant, and pedigree-compliant quadrupole training samples for full fine-tuning of the frozen backbone decoder (LLaMA-38B backbone). The training phase reads demand tokens. Convention token With the final code sample Perform supervised objectives (such as next-token or prefix-to-code tasks) while retaining lineage tokens for sample weighting or auditing.

[0401] Sampling example strategy (during full fine-tuning):

[0402] Construct batches based on task settings: Each batch extracts N nearest neighbor samples of demand tokens from the Faiss index, and then balances them according to time and diversity rules to form the final batch.

[0403] Sample importance weights can be introduced: for example, assigning higher weights to samples with final_status=ACCEPTED, and reducing or excluding samples with FORCED_ACCEPTED or NON_CONVERGENT.

[0404] Lineage constraints or compliance regularization (using specification tokens) can be added to the training loss. Constraint regularization is performed to improve the model's sensitivity to reduction.

[0405] After the quadruple is written, a unique event ID (based on the hash of blood hex + offset + timestamp) is generated and written to the audit chain. The audit chain retains all verification evidence, LoRA update history and replacement snapshots. Any quadruple can be quickly located through the index and its generation process can be traced (generating random seeds, replacing candidate pools, and joint probability sequences of each round), which meets the interpretability and reproducibility requirements of GJB-5000A and ISO-26262 audit requirements.

[0406] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A dual-agent collaborative code generation data method for training large models, characterized in that, Includes the following steps: Step 1: Input a composite cue vector containing demand tokens, specification tokens, and lineage tokens into the generative agent. The generative agent, through a heterogeneous decoding stack consisting of a backbone decoder with frozen weights and an adapter connected in series, autoregressively outputs a sequence of candidate code tokens to form an initial code sample, including: Step 1-1: In the offline phase, a rule-neural network hybrid extractor is used to parse the license-cleaned compliant source code library file by file. For each function-level code snippet, a requirement token is generated using the function signature as the anchor. The requirement token is a fixed-length 768-dimensional vector representation composed of a natural language description of the function's functionality, a list of input and output tensor shapes, and an industry standard identifier. Simultaneously, an abstract syntax tree traversal and a data flow graph traversal are performed on the source code with the same function signature. The node attributes obtained from the traversal are serialized into a specification token. The specification token is a fixed-length 1024-dimensional vector representation composed of an abstract syntax tree node type sequence, a data flow graph edge type sequence, and a security criticality level marker. Subsequently, a globally unique lineage token is generated based on the Git commit hash, repository URI, and starting line number. The lineage token is a 256-bit binary vector representation composed of a 160-bit SHA-1 hash value, a 32-bit timestamp, and a 16-bit license number. Steps 1-2: Concatenate the demand token, specification token, and lineage token column-wise to form a composite cue vector, and insert a learnable separator embedding at the concatenation point to obtain a composite cue vector with dimensions (3, 768); input the composite cue vector into the generating agent, which consists of a heterogeneous decoding stack composed of a frozen weighted LLaMA-3 8B backbone decoder and a low-rank adapter containing only 0.1% trainable parameters, wherein the low-rank adapter uses a LoRA matrix with a rank of 16 to bypass the Query and Value projection layers of the backbone decoder; Steps 1-3: In the autoregressive generation stage, the heterogeneous decoding stack uses a temperature annealing sampling strategy to decode the composite cue vector with a linear annealing temperature of 0.8→0.2, outputting a candidate code token sequence with a maximum length of 512. After restoring the candidate code token sequence by word inverse mapping and whitespace characters, an initial code sample that can be directly sent to the compiler is obtained. The initial code sample is a plain text string encoded in UTF-8, with lineage token hexadecimal representation appended to its beginning and end as an uncompileable comment for rapid source tracing in the subsequent verification stage. Step 2: Inject the initial code sample into the parallel verification pipeline driven by the verification agent. The verification agent calls the semantic encoder, which shares weights with the generating agent, to extract the graph structure of the initial code sample to obtain the abstract syntax tree token and the data flow graph token. The abstract syntax tree token, the data flow graph token, and the requirement token are then subjected to ternary cross attention calculation to generate the compilation success probability, specification compliance probability, and lineage integrity probability in real time. Step 3: When the joint probability of compilation success, specification compliance, and lineage integrity is lower than a preset threshold, the verification agent encodes the misalignment of the abstract syntax tree token, data flow graph token, and initial code sample into a negative reward gradient, and backpropagates the negative reward gradient to the adapter of the generating agent through the backpropagation channel to achieve real-time weight updates. After correction, the agent is generated. Step 4: After correction, the generated agent replaces the misaligned positions of the initial code sample with a mask according to the negative reward gradient, re-decodes the supplementary code sample, and splices the supplementary code sample with the initial code sample according to the tracing identifier recorded in the lineage token to form a merged code sample with an incremental lineage chain. Step 5: The verification agent executes the parallel verification pipeline again on the merged code sample. If the joint probability reaches the preset threshold, the merged code sample is output. If it still does not reach the threshold, the merged code sample is marked as the secondary initial code sample and steps 2 to 4 are executed repeatedly until the joint probability reaches the preset threshold or the number of iterations reaches the upper limit, and the final code sample is obtained. Step 6: Encapsulate the final code sample and its corresponding requirement token, specification token and complete lineage token into a four-tuple training sample, and write it into the data pool for training large models, for subsequent full fine-tuning of the generative agent backbone decoder.

2. The method for dual-agent collaborative code generation data for large model training according to claim 1, characterized in that, Step 2 includes: Step 2-1: Inject the initial code sample into the parallel verification pipeline driven by the verification agent. The parallel verification pipeline consists of three parallel processes: a compiler container pool, a static specification checking engine, and a lineage tracing microservice. The three processes share the same POSIX message queue and read the memory image of the initial code sample in a zero-copy manner. Step 2-2: Verify the semantic encoder that shares the weights of the agent calling and generating the agent. Extract the graph structure from the initial code sample. The semantic encoder is the first 18 layers of the Transformer block of the LLaMA-3 8B backbone decoder with frozen weights. The output hidden state is linearly projected to obtain the node feature matrix. The node feature matrix is ​​then fed into the edge prediction head and the type prediction head to generate the abstract syntax tree token and the data flow graph token, respectively. The abstract syntax tree token is represented by a fixed-length 256-vector sequence consisting of triples of node type number, parent node pointer, and child node pointer. The data flow graph token is represented by a fixed-length 256-vector sequence consisting of triples of variable definition-use edge, control dependency edge, and data type edge. Steps 2-3: Concatenate the abstract syntax tree token, data flow graph token, and requirement token into a ternary token tensor at the channel dimension. Perform three scaling dot product attention operations through the ternary cross attention calculation module. Each time, use one token as the query and the other two tokens as the key-value pair to generate the compilation success probability, specification compliance probability, and lineage integrity probability. The compilation success probability is a 0-1 floating-point value returned by the compiler container pool, the specification compliance probability is a 0-1 floating-point value returned by the static specification check engine, and the lineage integrity probability is a 0-1 floating-point value returned by the lineage tracing microservice. Steps 2-4: The verification agent fuses the compilation success probability, specification compliance probability, and lineage integrity probability into a joint probability using learnable weighted coefficients. These weighted coefficients are obtained by the verification agent during offline training by maximizing the F1-score objective function. The joint probability is written to a shared message queue in real time for reading in step 3.

3. The dual-agent collaborative code generation data method for large model training according to claim 1, characterized in that, Step 3 includes: Step 3-1: When the joint probability of compilation success, specification compliance, and lineage integrity is lower than the preset threshold of 0.95, the verification agent immediately starts the negative reward gradient construction submodule. This submodule performs element-wise subtraction of the cosine similarity difference between the abstract syntax tree token and the requirement token at the misaligned node position, the Euclidean distance difference between the data flow graph token and the reduction token at the misaligned edge, and the token-level edit distance difference between the initial code sample and the standard sample, and then concatenates them to form a negative reward gradient tensor with the same dimension as the lightweight adapter weight. Step 3-2: Verify that the agent transmits the negative reward gradient tensor through the backpropagation channel with a learning rate of 1×10⁻ 4 The data is directly transmitted back to the lightweight adapter that generates the agent. The backpropagation channel is implemented by the PCIeBAR0 memory area shared by the verification agent and the generating agent. The negative reward gradient tensor is written to the LoRA matrix A and LoRA matrix B of the lightweight adapter in a zero-copy manner with FP16 precision to complete the weight update in real time and generate the agent after correction. Step 3-3: After correction, the generated agent maps the negative reward gradient tensor back to the token sequence of the initial code sample according to the node position, applies a probability mask to the mapped position, and the mask value is obtained by normalizing the absolute value of the negative reward gradient tensor. The masked token position is forcibly replaced with the candidate token with the second highest probability in the vocabulary during the next round of autoregressive decoding, so as to achieve accurate correction of misaligned positions.

4. The dual-agent collaborative code generation data method for large model training according to claim 1, characterized in that, Step 4 includes: Step 4-1: The corrected generated agent receives the negative reward gradient tensor. Each element in the negative reward gradient tensor corresponds one-to-one with the token position of the initial code sample. The corrected generated agent marks the positions corresponding to the elements in the negative reward gradient tensor with absolute values ​​greater than zero as misaligned positions and applies binary masks to these misaligned positions. Positions with a mask value of 1 indicate that they need to be replaced, and positions with a mask value of 0 indicate that the original token is retained. Step 4-2: After correction, the generated agent performs token-level replacement on the misaligned positions with a mask value of 1. During replacement, guided by the sign direction of the negative reward gradient tensor, the top 5 candidate tokens with the highest cosine similarity to the reduced token in the vocabulary are selected to form a candidate pool. Then, a token is randomly sampled from the candidate pool as the replacement token. After the mask replacement is completed, the corrected token sequence is obtained. Step 4-3: After correction, the generated agent re-inputs the correction token sequence into the heterogeneous decoding stack and re-decodes the supplementary code sample through one forward propagation. The supplementary code sample is a plain text string encoded in UTF-8, with the lineage token's hexadecimal representation appended to its beginning and end. Step 4-4: After correction, the generated agent reads the traceability identifier recorded in the lineage token. The traceability identifier is a 256-bit binary vector. The supplementary code sample and the initial code sample are concatenated byte-by-byte according to the traceability identifier. During the concatenation, an incremental lineage chain marker is inserted at the boundary between the two. The incremental lineage chain marker is formed by XORing the SHA-1 hash value of the supplementary code sample and the SHA-1 hash value of the initial code sample and then encoding them with Base64, thus forming a merged code sample with an incremental lineage chain.

5. The method for dual-agent collaborative code generation data for large model training according to claim 1, characterized in that, Step 5 includes: Step 5-1: The verification agent executes the parallel verification pipeline again on the merged code sample to obtain new compilation success probability, specification compliance probability, and lineage integrity probability. The new compilation success probability, specification compliance probability, and lineage integrity probability are then multiplied element-wise by the learnable weighted coefficients and summed to obtain a new joint probability. Step 5-2: The verification agent compares the new joint probability with the preset threshold of 0.

95. If the new joint probability is greater than or equal to the preset threshold of 0.95, the verification agent immediately outputs the merged code sample as is and skips the subsequent loop. Step 5-3: If the new joint probability is less than the preset threshold of 0.95, the verification agent marks the merged code sample as a secondary initial code sample. The text content of the secondary initial code sample is completely consistent with the merged code sample. At the same time, the verification agent increments the iteration counter of the secondary initial code sample by 1. Before the iteration counter reaches the upper limit of 100 times, the secondary initial code sample is re-injected into the parallel verification pipeline described in step 2, and steps 2 to 4 are executed in a loop. Step 5-4: When the iteration counter reaches the upper limit of 100 times or the new joint probability in a certain loop is greater than or equal to the preset threshold of 0.95 for the first time, the verification agent terminates the loop and officially names the currently held merged code sample or secondary initial code sample as the final code sample. The final code sample is a UTF-8 encoded plain text string with a complete lineage token hexadecimal representation appended to its beginning and end, which is used for encapsulating subsequent quadruplet training samples.

6. The dual-agent collaborative code generation data method for large model training according to claim 1, characterized in that, Step 6 includes: Step 6-1: Sequentially encapsulate the final code sample and its requirement token, specification token, and complete lineage token, which remain unchanged throughout the process from Step 1 to Step 5, into a quadruple training sample. The quadruple training sample includes the requirement token, specification token, final code sample, and lineage token. Each part is arranged continuously in memory and has a fixed length of 768 dimensions, 1024 dimensions, 512 bytes, and 256 bits, respectively. A 16-byte length identifier is inserted between the four parts to support fast offset addressing. Step 6-2: Perform integrity verification on the quadruple training sample. The verification method is to first calculate the SHA-1 hash value of the final code sample, and then compare it bit by bit with the 160-bit hash value embedded in the lineage token. If the comparison results are consistent, the quadruple training sample is determined to be complete. If they are inconsistent, it is discarded and the process is reversed to step 5 to obtain the final code sample again. Step 6-3: Write the quadruple training samples that have passed the integrity check into the data pool for large model training in the form of a memory-mapped file. The data pool is a pre-allocated 100GB incremental memory-mapped file. When writing, a sequential append strategy is adopted. The writing address is determined by the 32-bit timestamp in the lineage token to ensure that the quadruple training samples are stored continuously in time order in the data pool. Step 6-4: After the data pool is written, trigger the asynchronous index building thread. This thread uses the demand token as the key and the offset address of the four-tuple training sample in the data pool as the value to build an inverted index based on Faiss-IVF1024, which is used for fast sampling when performing full fine-tuning on the generated agent backbone decoder.

Images