Knowing When Not to Reuse: Conditional Experience Transfer in Autonomous LLM Post-Training

Tingyun Li, Wenfeng Feng, Weiqing Li, Abudukelimu Wuerkaixi, Guohua Liu, Yuewei Zhang

BCIT prevents harmful LLM post-training updates by binding past experience to source conditions rather than treating it as universal permission.

How can autonomous LLM post-training systems decide whether to reuse a past training update or perform a new one, while avoiding harmful performance regressions?

Autonomous post-training systems often reuse past update evidence to guide future training, but an update that worked on one model checkpoint can be harmful or ineffective when applied to a different parent. Boundary-Calibrated Intervention Transfer (BCIT) explicitly authorizes experience reuse by checking source-context evidence, applicability conditions, and hard conflicts before allocating any full-training compute. On a 4B model, BCIT authorizes 25% of harmful candidates compared to 62.5% for additive baselines, while maintaining higher final-model quality under equal compute budgets.

Paper Primer

BCIT functions as a gatekeeper between candidate generation and weight-changing training. It evaluates each candidate using a transparent score that multiplies source-evidence strength by current-context compatibility, vetoing any candidate with a named hard conflict.

The method acts like a strict project manager: it reviews the "provenance" of a past success, checks if the current environment matches the original requirements, and forces a small-scale "validation trial" if the evidence is ambiguous before approving a full-scale training run.

BCIT significantly reduces the authorization of harmful updates while preserving beneficial ones.

In an audit of 24 candidate-context pairs, BCIT authorized only 25% of harmful candidates, whereas a standard additive policy authorized 62.5%. Harmful authorization dropped by 37.5 percentage points, while beneficial-candidate coverage remained at 90%.

BCIT improves final-model quality under equal compute constraints.

Across six paired end-to-end episodes, BCIT outperformed the Flat-Additive baseline by a mean of 2.63 points on a cross-task performance metric. The improvement was consistent across all six paired runs, with a 95% confidence interval of [2.10, 3.16].

Why is "conditional experience transfer" a problem worth solving?

Because autonomous systems often treat past successes as context-free instructions, leading them to waste compute on updates that are incompatible with the current model checkpoint or training stage.

How does BCIT handle candidates that lack clear historical evidence?

Candidates without observed source effects—such as new proposals—are routed to a bounded current-state validation trial, ensuring they only receive full-training budget if they pass a short, budget-capped test on the current parent model.

BCIT assumes that applicability conditions and hard conflicts can be prespecified by humans; it does not attempt to learn these boundaries, focusing instead on transparent, rule-based authorization.

For autonomous post-training, the decision to train is as critical as the training itself; BCIT demonstrates that treating experience as state-bound evidence rather than universal permission is essential for stable, compute-efficient model adaptation.

Introduction and Motivation

We expose why blindly reusing past update evidence wastes compute and can degrade model performance.

Autonomous post‑training pipelines repeatedly propose, train, and evaluate candidate updates, accumulating a history of outcomes. Because each update’s effect depends on the parent model, data mixture, and training stage, treating past successes as universally applicable can squander compute and even degrade subsequent training trajectories. This tension defines the problem of conditional experience transfer.

When an autonomous system applies a candidate update without checking whether the evidence that justified the update still holds for the current model, it may waste expensive training cycles and harm downstream performance.

Blind autonomous updates can consume large amounts of training compute while risking model degradation.

Related Work

We situate BCIT among prior autonomous post‑training, transfer, and sequential adaptation works.

Autonomous post‑training agents such as LaMDAgent and TREX automate data selection and pipeline revision, while AutoML systems like AutoPipe and EvoTrainer leverage past runs to guide configuration choices. Experience‑transfer and sequential‑adaptation literature also address related challenges, but none target the pre‑full‑training decision that BCIT formalizes.

A baseline that simply adds each candidate update’s effect to the current model without any interaction or scaling.

Agent‑driven system that automates post‑training data selection and pipeline revision, enabling continuous improvement without human intervention.

Framework for autonomous revision of post‑training pipelines, focusing on iterative improvement of model performance.

Benchmark suite for evaluating autonomous post‑training agents under controlled compute budgets.

Reinforcement‑learning benchmark for assessing agents that manage post‑training pipelines.

AutoML system that learns dataset‑conditioned configuration rankings to guide pipeline choices.

System that tracks model versions, diagnostics, failures, and reusable training skills to inform future training decisions.

Maps relationships among visual tasks to predict transferability between them.

Estimates transferability at the representation level by evaluating linear probes on pretrained models.

Metric that quantifies transferability of pretrained models by estimating the log‑maximum‑evidence.

Research investigating scenarios where source information harms target performance.

Methods that retrieve and adapt past cases, reflections, or workflows to solve new problems.

Approaches that store and recall past training episodes to guide future updates.

Technique that combines fine‑tuning deltas from multiple tasks to produce a composite model.

Method that averages the weights of multiple trained models to improve robustness.

Procedure that merges trained models while addressing compatibility issues at integration time.

Study of methods that acquire new capabilities while limiting forgetting of previously learned tasks.

Problem Formulation

Defines the decision unit that pairs a candidate update with its current training context.

A decision unit is the exact moment we ask: given the current training snapshot and a single atomic update, should we spend compute to apply it? By binding a candidate to its concrete context, the effect of that update becomes directly observable and comparable.

How does this decision unit differ from a conventional policy that directly selects actions?

A conventional policy maps a state to an action without keeping a record of the action’s observed effect. The State‑Bound Decision Unit explicitly pairs a candidate $i$ with its concrete training snapshot $x_t$, and the label (Beneficial/Harmful/Neutral) is assigned only after the full‑budget outcome $\Delta_{\text{out}}$ is measured. This retrospective, context‑specific labeling prevents blind execution of updates and makes the impact of each atomic change interpretable.

Full‑budget training of the candidate yields a new model $m^{+}_{t}(i)$ whose accuracy rises from $70\%$ to $71\%$.

Compute the outcome delta: $\Delta_{\text{out}}(i; x_t) = 71\% - 70\% = 1\%$ improvement.

With target threshold $\kappa_{\text{tar}} = 0.5\%$ and no retention loss ($\epsilon_r = 0$), the outcome satisfies the Beneficial criteria.

If the learning‑rate change had instead reduced accuracy to $68\%$, the delta would be $-2\%$, violating the target improvement and labeling the outcome Harmful.

The unit shows that even a modest learning‑rate tweak can be judged beneficial without retraining every possible candidate, because the decision is anchored to the concrete context $x_t$ and measured outcome $\Delta_{\text{out}}$.

Authorization Policies

Define how the system decides which updates to run within a fixed GPU budget.

Blindly applying every candidate update burns compute and can degrade the model, so a disciplined decision step is essential.

The policy inspects each candidate update and decides whether to discard it, run a cheap trial, or spend the full budget to train it.

Step 1: Apply the policy to $c_1$ → Choose Validate (spends 3 units, remaining budget 7).

Step 2: Validation of $c_1$ yields modest improvement; the temporary checkpoint is not promoted.

Step 3: Apply the policy to $c_2$ → Choose Train (spends the remaining 7 units, budget exhausted).

Step 4: $c_2$ completes full training, becoming the new parent model.

Validation can consume part of the budget but never replaces the parent; only a Train action can change the model despite the same total budget.

Initialize remaining budget $B_{\text{gpu}}$ and empty cost accumulator $C_{\pi}=0$.

Iterate: generate a candidate $c_i$ and invoke the Authorization Policy to obtain action $a(c_i, x_t)$.

If action is Validate, deduct the trial cost from $B_{\text{gpu}}$ and add it to $C_{\pi}$; collect evidence but do not update the parent.

If action is Train, deduct the full training cost, update the parent model, and add the cost to $C_{\pi}$.

If action is Reject, incur no cost and proceed to the next candidate.

Terminate when $C_{\pi}$ reaches $B_{\text{gpu}}$ or no further candidates remain.

Return the final model $m_{\pi}(B_{\text{gpu}})$ and compute utility $U$ and retention metrics $G_r$.

BCIT Mechanism

BCIT gates candidate updates by checking past evidence and current fit before full training.

Blindly applying every candidate update wastes compute and can degrade model quality. BCIT addresses this pain by refusing to train on updates that lack supporting historical evidence or that clash with the current context.

BCIT is a gate that authorizes a historical candidate for full training only if its past impact and its fit to the current context both look trustworthy.

Candidate 1: $S_1 = 1 \times \operatorname{clip}(0.4/0.5,0,1) = 0.8$.

Candidate 1: $A_1 = (1+0.5)/2 = 0.75$.

Candidate 1: $Q_1 = 0.8 \times 0.75 = 0.60$ → passes the acceptance threshold, so it is authorized for full training.

Candidate 2: $S_2 = 0.75 \times \operatorname{clip}(0.2/0.4,0,1) = 0.75 \times 0.5 = 0.375$.

Candidate 2: $A_2 = (0+0.5)/2 = 0.25$.

Candidate 2: $Q_2 = 0.375 \times 0.25 = 0.094$ → below threshold, so it is rejected.

Even a relatively strong source ($S_2=0.375$) cannot rescue a candidate with poor compatibility ($A_2=0.25$); both scores must be jointly high.

How does BCIT differ from a simple flat‑additive baseline that just adds the source delta to the current model?

The flat‑additive baseline would apply $\delta_{src}$ regardless of current compatibility, potentially harming performance when the context has changed. BCIT multiplies $\delta_{src}$ (after discount) by a compatibility factor $A_i$, and it also blocks any candidate that triggers a hard conflict $H_i=1$, guaranteeing that both past evidence and present fit are required.

BCIT authorization logic.

Validation and Execution

The section introduces a short validation proxy that vets candidate updates before full training.

The core trick is to run a short, budget‑capped validation proxy before allocating full‑training resources, preventing wasted compute and harmful updates.

Start from the current parent model $mt$ and apply the candidate update under a capped budget $\\bar{b}_{val}$.

Train for $i \\le \\bar{b}_{val}$ steps, yielding $b_{val}^{mt}=\\text{Train}(mt,i,b_{val_i})$.

Compute the metric change $\\Delta_{val_i}=M_{val}(mt)-M_{val}(b_{val}^{mt})$ using frozen evaluation data.

Compare $\\Delta_{val_i}$ against the validation threshold; if it meets the target and all retention bounds hold, label the run **Pass**.

If a frozen degradation or guardrail fires, label **Fail**; otherwise label **Inconclusive**.

Route Pass → full training; Fail → reject; Inconclusive → conditional full training based on fallback lease.

A lightweight, budget‑limited run that checks whether a candidate update would improve the model before spending full training resources.

Step 1: $i=1$, compute $\\Delta_{val_1}=0.58-0.55=0.03$.

Step 2: $i=2$, compute $\\Delta_{val_2}=0.62-0.55=0.07$.

Compare $\\Delta_{val_2}=0.07$ to the high threshold $\\tau_h=0.70$ (scaled to the metric’s range); it does not exceed $\\tau_h$, but it is above the low threshold $\\tau_l=0.30$, so the proxy classifies the run as **Pass**.

The proxy can certify improvement with only two training steps, avoiding the cost of a full‑scale run.

**Figure 4.** Candidate-level bounded-validation fidelity. Circles and triangles denote SFT and GRPO; open rings mark the four sign reversals.

How does this Validation Proxy differ from a standard early‑stopping check?

Early stopping monitors training loss on the same run and stops when improvement stalls, whereas the Validation Proxy runs a separate, budget‑capped short run on frozen data before any full training begins. It therefore evaluates candidate quality without consuming the full training budget.

Memory and History

We limit proposal bursts and enforce provenance‑checked updates via a bounded‑exploration memory.

Autonomous agents often waste compute by flooding the system with unchecked updates, and performance degrades when incompatible changes are applied. To curb this, we impose a strict proposal budget and a provenance‑aware filter that only admits updates passing compatibility and strength checks.

Think of the memory as a guarded bookshelf that only lets a few new books in after the librarian verifies they belong to the right genre and fit the existing collection.

Proposal 1: change $c_1$ with context $x_s$ from history entry 1; compute $Q_1 = S_1 \times A_1 = 0.8$.

Since $Q_1 \ge \tau_h=0.5$ and $\chi_1=1$, the proposal passes the compatibility filter and is authorized for full training.

Proposal 2: change $c_2$ conflicts with a recorded failure ($H_2=1$); the veto rule immediately rejects it.

Proposal 3: change $c_3$ has $Q_3 = 0.3 < \tau_l=0.4$; it fails the low‑threshold check and is discarded without training.

The budgeted limit $q=3$ prevents a cascade of low‑quality updates, while the veto rule stops any proposal that would repeat a known failure.

How does this bounded‑exploration memory differ from a naïve approach that generates unlimited proposals?

The naïve approach would let the agent emit arbitrarily many updates, many of which could conflict with past failures or be low‑quality, leading to wasted compute and degraded performance. Our mechanism caps the number of atomic proposals at $q$, enforces a hard veto on any $H_i=1$ conflict, and requires a compatibility score above $\tau_h$, guaranteeing that only a few well‑vetted updates are trained.

BCIT provides the baseline authorization logic, but the memory mechanism above augments it by adding a strict proposal cap and provenance‑aware vetoes, ensuring that only compatible, high‑confidence changes survive.

Imagine three different gatekeepers: one adds all evidence together, another adds evidence but still blocks hard conflicts, and a third lets every candidate pass the gate regardless of evidence.

Why does BCIT retain a hard veto ($H_i=1$) while Flat‑Additive drops it?

BCIT’s hard veto guarantees that any update previously observed to cause a failure is never retrained, preserving safety. Flat‑Additive replaces the veto with a soft penalty, allowing a strong source evidence $S_i$ to compensate for a conflict; this relaxes safety but can increase acceptance of otherwise rejected proposals, which changes the overall trade‑off between robustness and flexibility.

Experimental Protocol

Key results show BCIT balances benefit and risk while outperforming baselines across three tasks.

Recall that BCIT selectively authorizes model updates by checking historical validation data, preventing wasteful or harmful changes.

Effect heterogeneity is pronounced: most candidate updates fail to improve the target metric.

Thirteen of the 24 audited candidate–context pairs do not improve their target.

BCIT reduces harmful authorizations while preserving beneficial candidates, achieving low harmful‑candidate rates and high beneficial‑candidate coverage compared to Flat‑Additive, Validate‑All, and Additive+Veto.

**Figure 2.** Candidate updates exhibit heterogeneous target and retention effects across 24 matched candidate–context pairs. (a) Target-direction counts (n = 8 per family); arrows redundantly encode direction. (b) Target change versus the worse IFEval change. The gray [−2, 2] band is linear; the disclosed symmetric-log scale compresses only larger retention changes. Semantic labels replace run identifiers.

Results and Analysis

BCIT delivers higher scores while cutting harmful updates under equal compute.

Recall that BCIT selectively authorizes updates by checking historical validation data, avoiding the blind‑apply waste that hurts standard post‑training pipelines.

BCIT improves the final mean task score over Flat‑Additive by +2.63 points.

Table 2 shows a mean of 47.0 vs 44.4 across six paired runs.

**Figure 3.** Observed equal-budget trajectories. Mean task score versus consumed budget; BCIT and Flat-Additive bands are $\pm 1$ sample SD over six paired seeds.

Table 2 aggregates the 36‑GPU‑hour endpoint results, confirming that BCIT dominates across all six performance columns while using the same compute budget.

Limitations and Conclusion

BCIT authorizes updates only when past validation deems them compatible, avoiding wasteful blind changes.

BCIT selectively authorizes post‑training updates using historical validation data, preventing wasteful blind changes. This avoids compute waste and performance degradation.

Our evidence is limited to a single $4$ B model, three target capabilities, and one retention benchmark, all under human‑specified boundaries. The four studies share candidates and are complementary rather than independent replications, with complete‑policy comparisons using only six paired seeds. Consequently, validation fidelity and compute trade‑offs may differ at larger scales, with different data or schedules, and learned boundaries, broader domains, and longer trajectories remain open research.

BCIT enforces a distinction: it rejects hard conflicts, validates unresolved candidates on the current parent, and grants full‑training budget only under a frozen rule. A shared‑policy adoption step then promotes or rolls back each trained child, yielding fewer harmful updates while preserving beneficial ones. Across evaluated settings, BCIT achieves higher cross‑task means and AUC under matched compute, uses less GPU‑hours than alternatives, and maintains IFEval scores above prespecified margins, supporting evidence‑conditioned allocation of post‑training compute.

Supplementary Overview

Additional details on study design, controller logic, and evaluation tables.

The supplement separates four empirical components—Retrospective‑24, Audit‑24, ShortFull‑24, and full episodes—each answering a distinct question while keeping results isolated.

Retrospective‑24 documents heterogeneous effects across candidate–context pairs but does not claim policy superiority; Audit‑24 evaluates authorization after decisions are frozen; ShortFull‑24 measures a mechanism used by the policy while sharing outcomes with Audit‑24; full episodes compare complete sequential policies where earlier decisions alter later parent models.

The controller contract freezes the episode state $Ω = (L_0, K_0, R, \Gamma, D_{cal}, D_{val}, D_{prom}, D_{final}, g, \Theta, B)$, which records the base model, seed, memory snapshots, candidate inventory, retrieval order, evidence grades, score thresholds, validation compiler, proposal quota, evaluators, parsers, data roles, resource cap, stopping rule, and analysis specification.

Evidence grades are discounted as $d(A)=1.00$, $d(B)=0.75$, $d(C)=0.50$; only grade A may bypass current‑state validation, yielding a raw score offset $κ_i=0.02$. Applicability $Q_i$ is the mean of five pre‑training fields scored 0, 0.5, or 1, with a hard conflict $H_i=1$ vetoing any candidate.

Authorization follows rule (25): a historical candidate $a(chist_i, x_t)$ is rejected if $H_i=1$ or $Q_i<τ_l$, trained if $Q_i\ge τ_h$ and $χ_i=1$, validated if $ν_i\neq\text{None}$, otherwise rejected. A validation passes only when the target meets the frozen validation threshold and all retention bounds hold.

Adoption uses the utility $U_{src}=δ_{src}\cdot\text{clip}(δ_{src_i}/κ_i,0,1)$ and source strength $S_i=d(e_i)\cdot\text{clip}(δ_{src_i}/κ_i,0,1)$. Promotion requires a primary gain of $+0.5$ pp, non‑primary changes of at most $-1$ pp, and $U_{prom}>0$, where $U_{prom}=\frac{1}{|F|}\sum_{r\in F}\frac{Δ_{prom_r}}{κ_r}$.

Comparators include Flat‑Additive $Z_i=(S_i+A_i+1-H_i)/3$, Additive+Veto $Z_{add}=(S_i+A_i)/2$ with thresholds $0.45/0.75$, and Validate‑All which ignores $S_i$, $A_i$, and $H_i$ after the executability check.

Dataset roles assign FinQA, Spider, and xLAM as source update experience, while TAT‑QA, BIRD, and BFCL measure transfer to related targets; IFEval supplies 541 prompts and 834 verifiable instructions for strict accuracy evaluation.

Common training defaults let candidate cards inherit settings from Table 7; the method‑owned compute charge is $C = (j - t_{start})/[n_j\,(t_{end}\dots)]$ (formula truncated).

**Table 3.** Relationship between the four empirical components. Unit rows are observed candidate-level or episode-level values rather than reconstructed pseudo-observations.

The table presents performance metrics across different budget levels (5%, 10%, 20%). Columns include "Budget", "P/F/I", "Sign agree", "$\rho$", and "Median cost/full".

Evaluation Details

Supplementary details on evaluation protocols, tables, and audit metrics.

Evaluation is deterministic: each prompt yields a single sample, temperature 0, top‑p = 1. Finance uses a frozen numerical parser, SQL runs against the declared backend, BFCL checks structured calls, and IFEval applies the strict evaluator. Any API error, missing prediction, incompatible output, or unusable checkpoint is treated as a hard failure rather than a silent zero.

**Table 5.** Constructed authorization cases illustrating the frozen rule. These examples explain routing only; they are not experimental observations and do not contribute to any reported result.

**Table 6.** Capability families and frozen target-evaluation cohorts. Counts are evaluation examples, not training-set sizes.

**Table 9.** All Retrospective-24 matched effects in percentage points. Each row is intervention minus its matched control. P/I denote IFEval prompt/instruction strict accuracy.

The table presents a comparison of two methods, BCIT and Flat-Additive, across four metrics: Coverage, HER, BCov, and Harm/Auth. Each cell contains a numerical interval representing the performance range for the respective metric and method.

**Table 16.** Three-seed component ablations. $\Delta$ is the matched BCIT mean minus the ablation mean on S1–S3. These rows are descriptive and receive no significance test.

Table 7 enumerates the default hyper‑parameters for full‑parameter SFT: base model Qwen3‑4B, bfloat16 precision, DeepSpeed ZeRO‑2 optimizer, 4,096‑token context length, learning rate $6\times10^{-6}$, cosine scheduler with 0.03 warmup, weight decay 0.01, max gradient norm 1.0, per‑device batch 4 with accumulation 2, yielding an effective batch of 32 on four GPUs.

Audit metrics are defined from counts $B_{\pi}$ (beneficial), $H_{\pi}$ (harmful), and $N_{\pi}$ (neutral) for a policy $\pi$. Coverage$(\pi) = (B_{\pi}+H_{\pi}+N_{\pi})/24$, HER$(\pi)=H_{\pi}/8$, SelU2$(\pi)=(B_{\pi}-2H_{\pi})/24$, Harm/Auth$(\pi)=H_{\pi}/(B_{\pi}+H_{\pi}+N_{\pi})$, and BCov$(\pi)=B_{\pi}/10$.

RQ1 investigates retrospective transfer: among 24 candidate–target pairs, 11 improve the target, 3 are neutral, and 10 degrade it; only three of the eleven improvements also boost both retention measures.

RQ2 conducts an outcome‑blind authorization audit: a unit is labeled Beneficial (B) if it meets the target MCID, satisfies retention constraints, and incurs no hard failure; Harmful (H) if the target degrades, a retention bound is violated, or a hard failure occurs; Neutral (N) otherwise. The audit contains 10 B, 8 H, and 6 N units.

RQ3 evaluates bounded‑validation fidelity: all 24 frozen candidates proceed to full training regardless of short‑run outcomes. At a 20 % nominal budget, short‑run and full‑run directions agree for 20 of 24 candidates (83.3 %).

Rationale-first SQL SFT

Supplementary details on SQL SFT rationale, audit tables, and candidate ledger.

Rationale‑first SQL Supervised Fine‑Tuning (SFT) augments the base‑plus‑retention recipe with 260 train‑only SQL rationale examples, using executable SQLite databases and schema context as the primary evaluation metric.

Dialect or backend mismatches, as well as incompatible output schemas, are flagged as failure modes; each training artifact (data, config, evaluator, source outcome, run identifier) is hashed into a content digest for reproducibility.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers