Keywords: agent post-training, closed-loop control, release gating, supervised fine-tuning, application-chain evaluation

1 Introduction↩︎

Domain agents are increasingly used for data questioning, contract lookup, document QA, and process assistance. RAG is a common way to ground LLM applications with external evidence.^[1][9] LoRA and QLoRA make parameter-efficient domain adaptation practical.^[2][5] Instruction tuning, preference optimization, and RLHF further motivate post-training control for application behavior.^[3][4] Reasoning-and-acting agents, benchmarked agent behaviors, tool-use agents, and automated post-training pipelines further show that agent adaptation must be evaluated in the target application workflow.^{[15][16][17][18]} Such systems accumulate domain data and interaction traces, but raw business signals are not directly reusable post-training assets: they often contain noisy fields, inconsistent formats, incomplete evidence, and unstable labeling conventions. Whether a trained adapter improves business capability also requires reproducible evaluation and release gating.

This paper studies how to transform real business data into post-training assets that are trainable, diagnosable, evaluable, and releasable, and how to determine whether a trained adapter is suitable for the target application chain. Unlike purely algorithmic work, we focus on a system method and experiments on real business data. Using data from an anonymized manufacturing scenario as the case study, we design and validate the CLAP post-training workflow, including data construction, SFT/GRPO training, reward/KL risk checks, holdout evaluation, adapter gating, and application-chain replay.

The main contributions are fourfold: we propose a closed-loop training, evaluation, and release-control workflow for domain agent post-training; design target/evidence normalization for noisy structured extraction targets; conduct base-vs-QLoRA-style LoRA-SFT experiments on five batches of real manufacturing-domain data; and use batch-level regression, GRPO failure-boundary experiments, and application-chain replay to show why domain post-training requires diagnostics, guardrails, application-chain validation, and fallback rather than unconditional promotion.

2 Related Work and Positioning↩︎

Domain-agent optimization usually combines RAG, SFT, and preference/RL-style training. RAG provides business evidence but does not by itself teach stable output formats or decision preferences.^[1][9] SFT and PEFT improve format following, but they can regress when targets and evaluation are misaligned.^[2][5] DPO/GRPO-style methods express preferences but are sensitive to reward design, rollout quality, KL drift, and sample distribution.^[4][13] Recent international journal surveys on large language models and retrieval-augmented generation further motivate this governance-oriented positioning.^[8][9] Surveys on hallucination, parameter-efficient fine-tuning, and human-feedback learning also show that model adaptation must be evaluated together with factuality, risk, and feedback signals.^{[10][11][12][14]} CLAP does not propose a new model architecture or claim algorithmic superiority over full-parameter fine-tuning, RAFT, or Self-RAG.^[6][7] It addresses a production question: how to convert real business data into training assets, diagnose training risks, gate adapter release, and feed failure cases into the next data and training iteration.

3 CLAP Method and System Architecture↩︎

3.1 Task and Asset Definition↩︎

Given a domain business data collection \(D\), CLAP converts it into a post-training asset set: \[A = \{D_{\mathrm{sft}}, D_{\mathrm{grpo}}, D_{\mathrm{eval}}, C, G, R\}.\] where \(D_{\mathrm{sft}}\) denotes supervised fine-tuning data, \(D_{\mathrm{grpo}}\) denotes preference or decision training data, \(D_{\mathrm{eval}}\) denotes holdout evaluation data, \(C\) denotes data-construction and training configuration, \(G\) denotes gate rules, and \(R\) denotes training and evaluation records. The system goal is not to maximize a single training loss, but to make adapter release conditional on gate constraints: \[\mathrm{promote}(M') \Leftarrow \mathrm{quality}(M') \geq \mathrm{quality}(M) \land \mathrm{risk}(M') \leq \tau.\] where \(M\) is the base model or previous adapter, \(M'\) is the candidate adapter, and quality/risk are measured by holdout metrics, factual errors, KL, latency, and regressions. Otherwise, the candidate is held, canaried, or rejected.

3.2 Training Admission and Release Gating↩︎

CLAP decomposes training into two gates. The pre-training gate checks train/eval overlap, target/evidence verifiability, GRPO reward variance, and chosen/rejected ordering. The post-training gate compares the candidate adapter against the baseline using a configurable policy over quality, risk, latency, and critical regressions.

For SFT, this paper focuses on field, value, and evidence consistency in structured extraction. For GRPO, the method requires pre-training admission and runtime guardrails to be used together, so release readiness is not inferred from static reward distribution alone; the concrete risks are examined in the experiments.

Unlike a single-point gate that checks one final score, CLAP organizes release control across asset validation, training admission, runtime diagnosis, holdout regression checks, application-chain replay, and release/fallback records. Its decision object is a traceable evidence bundle, including dataset version, training configuration, adapter artifact, evaluation record, and regressed samples. Thus adapter release becomes traceable risk decision-making rather than one-time scoring.

3.3 Method Modules and Decision Logic↩︎

CLAP can be summarized as a control-oriented closed-loop post-training method: \[\mathrm{assetize} \rightarrow \mathrm{materialize} \rightarrow \mathrm{admit} \rightarrow \mathrm{train} \rightarrow \mathrm{evaluate} \rightarrow \mathrm{gate} \rightarrow \mathrm{app\;validate} \rightarrow \mathrm{release/fallback}.\] Table ¿tbl:tab:method-modules-en? lists the inputs, outputs, and decision roles of each module.

The main decision rules are compact: nonzero train/eval overlap blocks formal training; unverifiable targets or evidence go to data repair; weak GRPO reward gaps or ordering quality lead to SFT-only or hold; runtime KL, reward-drop, or length anomalies stop training; holdout regression or latency/error violations prevent promotion. If adapter-only replay cannot recover factual values or evidence, the adapter is treated as a structured-output enhancement component, not a RAG replacement.

3.4 System Architecture↩︎

CLAP is implemented as a post-training assetization and release-control system rather than a single training script. It separates data flow from control flow through four layers: asset, materialization, training control, and evaluation/release. Data flow converts raw business records and RAG chunks into dataset commits, sample indices, task-specific train/eval files, and adapter artifacts; control flow records admission, recipes, KL/reward/length risks, baseline comparisons, and promote/canary/hold/reject/rollback decisions. Versioned data management or Git-like database infrastructure can host dataset versions, experiment snapshots, and rollback points, but this paper does not evaluate the database layer itself. Failure cases are fed back to update data-construction rules, reward targets, and gate thresholds in the next iteration.

The agents studied here are business-assistant agents for data questioning, contract lookup, and RAG-based QA. We do not claim a full self-evolving loop based on online trajectories; the experiments focus on offline post-training asset construction, evaluation, and pre-release replay.

4 Data and Experimental Setup↩︎

4.1 Structured SFT Data↩︎

Structured SFT samples are built from RAG document chunks from the anonymized manufacturer. Each sample contains source material, target constraints, and expected JSON output with fields including entity, metric, period, value, unit, and evidence. In earlier data construction, some metric labels contained numeric values, such as “6,076.97, proportion of total raw material procurement”. Such value-bearing metric labels make the target unstable and affect holdout evaluation.

Therefore, v3 data construction introduces target/evidence normalization: it strips leading numeric values from metric labels, requires expected values and key metric terms to be verifiable in the input material, and removes ID or input overlap between train and eval splits.

4.2 Decision GRPO Data↩︎

Decision samples are built from business records such as material backlog and quality-loss reports. GRPO data is organized into groups. Each group contains a grounded chosen candidate, near-miss candidates, and rejected candidates. The reward design focuses on whether the action comes from the original handling suggestion, whether the reason cites the original cause fields, and whether the risk focus follows business rules.

In this paper, GRPO is not used as the main positive result. It is used as evidence for failure boundaries and the necessity of guardrails.

4.3 Application-chain Evaluation Data↩︎

To examine adapter boundaries, we replay batch_05 as pre-release application-chain validation. All replay groups use the same 100 cases. The new controlled application-side ABCD experiment uses the same local 3B backbone: A is 3B base+RAG, B is 3B application-RAG-oriented LoRA-SFT+RAG, C is 3B base-only, and D is 3B LoRA-SFT-only. This design separates two questions: whether RAG is necessary for factual extraction, and whether an application-oriented LoRA-SFT adapter can improve synthesis over retrieved evidence under the same 3B backbone. The earlier structured-SFT adapter is retained only as a reference case for training-objective/application-objective mismatch, not as a main table group.

4.4 Data Version and Configuration↩︎

The main experiment uses enterprise_manufacturing_v3. It contains five batches of structured SFT data, each with 100 holdout samples. After overlap cleanup, the training split contains 359–360 samples per batch.

The SFT configuration uses learning rate 2e-5, one epoch, per-device train batch size 2, gradient accumulation steps 8, and evaluation profile manufacturing_structured. The SFT condition uses Unsloth/PEFT with a 4-bit loaded base model and LoRA adapter training. The LoRA rank is 16 and alpha is 32, so we describe it as QLoRA-style LoRA-SFT. It is not full-parameter fine-tuning and does not constitute an algorithmic comparison against RAFT or Self-RAG.

4.5 Evaluation Metrics↩︎

Offline structured evaluation metrics include overall score, pass rate, field accuracy, value accuracy, evidence accuracy, hallucination rate, target match, wrong-fact rate, and p95 latency. Hallucination and wrong-fact rates are better when lower; other quality metrics are better when higher. Application-chain metrics include answer JSON parseability, value exact match, period exact match, all-core-fields exact match, evidence chunk/doc/page exact match, retrieved target chunk, and retrieved target doc/page.

5 Results↩︎

5.1 Component-level Interpretation↩︎

This section answers three CLAP decisions: whether data is trainable and evaluable, whether gains hold across batches, and whether a candidate adapter suits the target application chain. We therefore report data quality, batch-level regressions, GRPO runtime risk, and ABCD application-chain replay rather than only average scores.

Data quality validation confirms the formal experiment conditions: for all five v3 batches, holdout size is 100, training size is 359–360, and ID overlap, input overlap, noisy metric labels, and missing evidence are all zero after cleanup.

Table 1 maps CLAP modules to the observed risk types in this paper. We do not interpret these results as strict ablation optimality of every module. Instead, they show that without the corresponding module, a specific class of post-training risk may remain invisible in the data, training, or application chain.

3pt

5.2 Main Base-vs-SFT Results↩︎

As shown in Table 2, SFT improves overall score on 3 of 5 batches and yields small mean gains in overall, pass rate, value, evidence, and target match while reducing hallucination and wrong facts. The clearest gain is evidence-related: evidence accuracy improves by 0.0280 and hallucination decreases from 0.0260 to 0.0180. P95 latency decreases by about 297ms, but serving-path variance prevents treating it as a standalone stable gain. Per-batch overall deltas are -0.0101, -0.0006, +0.0076, +0.0183, and +0.0336 for batch_01 to batch_05. The first two batches show that average improvement alone cannot imply every business subdomain is releasable; CLAP turns such regressions into hold, repair, rematerialization, or canary decisions.

5.3 Risk Boundary and Application-chain Ablation Replay↩︎

Static group-aware admission passes all five GRPO batches, with rank-pass rate equal to 1.0, reward margin mean around 0.224–0.226, and reward std around 0.332–0.334. However, actual GRPO training remains highly sensitive to recipe choices. Table ¿tbl:tab:risk-app-en? summarizes KL risk and application-chain replay. KL here is a training-log risk signal for relative diagnosis and gating, not a universal cross-model threshold.

Panel A shows that static reward distribution is necessary but insufficient: all five batches pass static admission, yet runtime training produces extreme KL peaks. Even batch_05, whose Reward\(_T\) exceeds Reward\(_0\), is held for KL risk, so reward or rank-pass alone overestimates GRPO release readiness. Panel B uses the same 3B backbone; AnsEv is answer-evidence exactness and RetDP is retrieval hit rate. C/D obtain zero value and core accuracy, confirming that RAG is necessary and the adapter does not replace retrieval. With RAG, the application-oriented LoRA-SFT adapter improves value (0.85 vs 0.83), core fields (0.78 vs 0.71), and answer-evidence doc/page matching (0.45 vs 0.25), but increases P95 latency (4582ms vs 3799ms). Thus application replay turns adapter release into a quality-latency-risk decision rather than unconditional promotion.

6 Discussion, Limitations, and Conclusion↩︎

CLAP is positioned as a governance-oriented closed-loop method for domain-agent post-training, not as a new training algorithm. The current experiments use QLoRA-style LoRA-SFT and a guarded GRPO boundary study on one anonymized manufacturing scenario, so the conclusions should be interpreted at the method and release-control level rather than as universal algorithmic ranking.

Several limitations remain. First, the data volume is modest and scenario-specific. Second, the application replay still evaluates a bounded pre-release case set rather than full online production traffic. Third, full-parameter fine-tuning, RAFT, Self-RAG, and broader adaptation baselines are outside the present scope. Fourth, GRPO here mainly serves as evidence for failure boundaries and the need for guardrails, not as a stable positive recipe.

Even with these limits, the main result is clear: real business-agent post-training cannot be managed by training completion or a single offline score alone. Small average SFT gains can coexist with per-batch regressions; static GRPO admission can coexist with runtime instability; and offline structured gains do not guarantee application-chain readiness without replay. CLAP therefore provides a practical governance loop for turning business data into post-training assets and for deciding whether a candidate adapter should be promoted, canaried, held, or rolled back.