This page shows the chapter notebook with its saved results. Constructed examples do not measure competition gains.
Chapter 25: The Continuous Learning System
Try the decision first
How much of the noise behind a logged gain does averaging more fold seeds remove, and what does a seed-based threshold then keep?
Write your expectation before opening the worked results. Use the chapter activity to compare supported inputs. To change the calculation itself, run the notebook on GitHub.
Your answers stay on this page until you download them. They are not sent to a server.
Worked notebook and saved results
How much of the noise behind a logged gain does averaging more fold seeds remove, and what does a seed-based threshold then keep?
The chapter says a negative result is local evidence, that a retrieval note must be checked against a real decision, and that counting notes is not evidence the system helped. A note's gain has noise from the fold seed and from the finite sample; measuring both shows how far a seed check goes.
Constructed data. The effect, the number of candidates and the learner set the sizes; the direction (seeds shrink their own noise, not the sample's, and kept gains overstate) is the claim.
The experiment
Thirty-two constructed competitions of 1,200 rows with 10 baseline features and 16 candidate features: 5 carry a small true effect and 11 are pure noise. Each candidate's gain is the paired difference in 5-fold cross-validated AUC between baseline plus candidate and the baseline, with a ridge-regularized linear model as the learner, repeated over 10 fold seeds. A note averages the first s seeds (the control). Truth is each candidate's gain on 20,000 new rows. Two rules decide whether a note is kept: any positive gain, and a gain above twice the fold-seed standard error.
Calculation code
import numpy as np
from scipy.stats import rankdata
from kaggle_companion.activities._common import clean
SEED = 25
CAMPAIGNS = 32 # independent constructed competitions; each logs notes for 16 candidate features
N_ROWS, BASE_FEATURES, CANDIDATES, REAL = 1200, 10, 16, 5 # 5 candidates carry a small true effect, 11 are pure noise
EFFECT = 0.15 # true coefficient (log odds per standard deviation) of a real candidate
SEEDS = 10 # fold seeds tried for every candidate; a note with s seeds averages the first s
FRESH_ROWS = 20000 # new rows from the same generator: each candidate's true gain
RIDGE = 10.0
def auc(y, score):
ranks = rankdata(score)
positives = y.sum()
return (ranks[y == 1].sum() - positives * (positives + 1) / 2) / (positives * (len(y) - positives))
def fit_ridge(X, target):
"""Closed-form ridge regression on -1/+1 labels: a fast linear stand-in for a gradient-boosted baseline."""
A = np.column_stack([np.ones(len(X)), X])
penalty = RIDGE * np.eye(A.shape[1])
penalty[0, 0] = 0
return np.linalg.solve(A.T @ A + penalty, A.T @ target)
def predict(w, X):
return w[0] + X @ w[1:]
def cv_auc(X, y, fold_seed):
"""Pooled out-of-fold AUC of 5-fold cross-validation with this fold seed."""
folds = np.array_split(np.random.default_rng(1000 + fold_seed).permutation(len(y)), 5)
target, score = 2.0 * y - 1, np.zeros(len(y))
for val in folds:
fit_rows = np.ones(len(y), bool)
fit_rows[val] = False
score[val] = predict(fit_ridge(X[fit_rows], target[fit_rows]), X[val])
return auc(y, score)
def one_campaign(seed):
"""One competition: a fixed set of rows, a baseline, and 16 candidate features. Returns each candidate's per-seed gains and true gain."""
rng = np.random.default_rng(seed)
base_weights = rng.normal(0, 0.45, BASE_FEATURES)
beta = np.r_[np.full(REAL, EFFECT), np.zeros(CANDIDATES - REAL)]
def rows(n):
X, F = rng.normal(size=(n, BASE_FEATURES)), rng.normal(size=(n, CANDIDATES))
logit = X @ base_weights + F @ beta - 0.1
return X, F, (rng.random(n) < 1 / (1 + np.exp(-logit))).astype(int)
(X, F, y), (X_new, F_new, y_new) = rows(N_ROWS), rows(FRESH_ROWS)
base = np.array([cv_auc(X, y, s) for s in range(SEEDS)])
base_new = auc(y_new, predict(fit_ridge(X, 2.0 * y - 1), X_new))
out = []
for j in range(CANDIDATES):
augmented = np.column_stack([X, F[:, j]])
gains = np.array([cv_auc(augmented, y, s) for s in range(SEEDS)]) - base # paired: same folds, same rows
true = auc(y_new, predict(fit_ridge(augmented, 2.0 * y - 1), np.column_stack([X_new, F_new[:, j]]))) - base_new
out.append((j < REAL, gains, true))
return out
def run(seeds_averaged):
items = [c for i in range(CAMPAIGNS) for c in one_campaign(SEED * 1000 + i)]
seed_sd = float(np.mean([gains.std(ddof=1) for _, gains, _ in items])) # spread of one candidate's gain across fold seeds
logged = np.array([gains[:seeds_averaged].mean() for _, gains, _ in items]) # the number written in the note
real = np.array([r for r, _, _ in items])
true = np.array([t for _, _, t in items])
seed_se = seed_sd / np.sqrt(seeds_averaged)
rules = {}
for name, bar in (("any_positive", 0.0), ("seed_floor", 2 * seed_se)):
kept = logged > bar
rules[name] = {"bar": bar, "keeps_real": float(kept[real].mean()), "keeps_noise": float(kept[~real].mean()),
"precision": float(real[kept].mean()), "logged_of_kept": float(logged[kept].mean()), "true_of_kept": float(true[kept].mean())}
return clean({
"seeds_averaged": seeds_averaged, "candidates": len(items), "noise_candidates": int((~real).sum()), "campaigns": CAMPAIGNS,
"seed_sd": seed_sd, "seed_se": seed_se, "noise_spread": float(logged[~real].std()),
"true_gain_real": float(true[real].mean()), "true_gain_noise": float(true[~real].mean()),
"logged_gain_real": float(logged[real].mean()), "rules": rules,
}, digits=6) # the gains are a few ten-thousandths of AUC: keep enough digits for the ratios shown
Measure it across the control
The control is fold seeds averaged in each logged note. Each value below runs the whole experiment from the generator up.
Calculation code
import pandas as pd
from kaggle_companion.activities.ch25 import explain
VALUES = [1, 3, 10]
results = {value: run(value) for value in VALUES}
table = pd.DataFrame({str(v): explain(results[v], v)['metrics'] for v in VALUES})
print(table.to_string())1 3 10 Seed standard error of a note 0.00066 0.00038 0.00021 Spread of noise features' gains 0.00101 0.00081 0.00075 Seed floor (2 SE) 0.00132 0.00076 0.00042 Noise features kept by the seed floor 0.043 0.057 0.091 Real features kept by the seed floor 0.512 0.613 0.688
Look at it
The figure shows the default setting, fold seeds averaged in each logged note = 10.
Calculation code
import matplotlib.pyplot as plt
from kaggle_companion.activities.ch25 import draw, NCOLS, HEIGHT
DEFAULT = 10
fig, axes = plt.subplots(1, NCOLS, figsize=(6.6 if NCOLS == 1 else 10.4, HEIGHT), layout='constrained')
draw(axes, results[DEFAULT], DEFAULT)
plt.show()What the result says
A note averaging 10 seed(s) has a seed standard error of 0.00021, so the seed floor is 2 x 0.00021 = 0.00042. Across 352 pure-noise features the logged gains still spread by 0.00075, 3.6 times the seed error. The seed-floor rule keeps 0.091 of noise features and 0.688 of real ones; any positive gain keeps 0.170 of noise features. Kept notes log 0.00240 on average against a true 0.00094: 0.00240 - 0.00094 = 0.00146 of overstatement.
- Seed standard deviation of one run: 0.00066; with 10 seed(s) the standard error is 0.00021.
- Spread of the noise features' logged gains: 0.00075 (seed error 0.00021).
- Seed-floor rule: keeps 0.688 of real and 0.091 of noise features; precision 0.77.
- Kept notes: logged 0.00240 - true 0.00094 = 0.00146.
Apply this to your competition
- Fix and store the fold seeds and fold IDs with each note, so the number can be regenerated, as the chapter's reproduction checks require.
- Estimate the noise floor from pure-noise candidates (shuffled or random columns) run through the same pipeline, not only from re-seeding the folds.
- Expect a kept note's gain to overstate the true gain; confirm any note you will build on with fresh rows or a second, independent campaign.
- Record negative and null results with the same care: a near-zero gain inside the noise is information about the noise, not a permanent ban.
Book location: Chapter 25, Preserve Failures and Reproduction Conditions.
Apply a lesson from this chapter
Select a lesson whose conditions match your project. State how you would test it and what would make you reject it.
Parameterize repeated pipelines and change one factor per experiment
Conditions
- submission feedback is scarce and similar datasets share processing
Action
- Author advice: Build a configurable shared pipeline, save artifacts and maintain a one-change experiment log.
Check
- Proposed verification: Reproduce a prior run and check whether each score change maps to one recorded alteration.
Limits
- One-factor experiments may miss interactions; source does not provide quantified refactoring gains.
Pin dependency commits for historical multimodal reproductions
Conditions
- a reproduction depends on development-version model support
Action
- Proposed adaptation of source observation: Capture exact dependency commits and the environment from the successful run.
Check
- Proposed verification: Run a small model-loading and inference compatibility check before spending the full GPU budget.
Limits
- The missing historical SHA cannot be reconstructed from this packet; no full reproduction was performed.
Record late unsuccessful repair loops as unfinished evidence
Conditions
- iterative repair or reasoning adds latency under limited benchmarks
Action
- Proposed adaptation of source observation: Compare complete repair-loop quality and cost against a simple candidate generator before extending it.
Check
- Proposed verification: Use the same representative tasks and record token/runtime budgets and valid tests.
Limits
- Late trials lack adequate tuning and local validation, so no universal agent-loop or reasoning failure follows.
Verify a subset pipeline before launching a memory-heavy full run
Conditions
- full-data training has large memory requirements
Action
- Proposed conditional application: First run the recommended ten-percent script and verify expected results before the full script; the author recommends 256GB RAM and at least 200GB swap.
Check
- Proposed check: Check subset output schema and expected results, profile peak memory, then estimate and test full-run scaling.
Limits
- Subset success does not establish full-run feasibility; source full run recommends 256GB RAM plus 200GB swap due to inefficient code.
Eliminate avoidable randomness and retain runtime headroom
Conditions
- geometric evaluation combines stochastic and threaded solvers under a runtime cap
Action
- Proposed adaptation of source observation: Fix seeds, test deterministic threading and leave runtime margin beyond a successful local run.
Check
- Proposed verification: Repeat complete pipeline runs and compare exact outputs and worst-case wall time.
Limits
- Determinism can reduce speed; reported workload explanation is uncertain and a postdeadline success does not remove submission risk.
Persist seeded stratified validation indices
Conditions
- bagged classification runs require reusable validation partitions
Action
- Proposed: generate a seeded stratified shuffle split and save both index arrays.
Check
- Proposed: assert index disjointness, label proportions and immutable dataset order; use grouped splitting where related images require it.
Limits
- This source shows an implementation, without an isolated gain, execution result, or confirmed final-submission provenance. Historical dependencies and dataset assumptions require local checks.
Distinguish an original submission from a fixed-seed reproduction
Conditions
- publishing a reproduction with changed randomization
Action
- Proposed adaptation of source observation: Label reproduced scores separately and retain the original and reproduced submission artifacts.
Check
- Proposed verification: Check whether changes in seed, fold membership and selected weights explain discrepancies.
Limits
- The metric is not named in this span and the scores do not isolate a method comparison.
Persist image records with a documented validation split
Conditions
- image training repeatedly reads the same corpus
Action
- Proposed adaptation of source observation: Persist a model-ready record format and retain explicit split provenance.
Check
- Proposed verification: Check sample/label parity and profile loader throughput against raw files.
Limits
- The source claims ease of use but gives no speed or reliability comparison.
Couple an experiment configuration with statistics and prediction outputs
Conditions
- many feature and model configurations are compared
Action
- Proposed adaptation: Persist the exact experiment configuration and its statistics alongside each prediction artifact.
Check
- Proposed verification: Verify output filenames resolve unambiguously to configuration content and data versions.
Limits
- Output naming alone does not guarantee complete provenance; bind data versions and configuration content explicitly.
Save validation membership as an explicit artifact
Conditions
- saved models cannot reconstruct their original split
Action
- Proposed conditional application: Persist train/validation IDs alongside checkpoints for later error analysis.
Check
- Proposed check: Reload checkpoint and explicit split IDs; assert membership/hash parity before comparing errors.
Limits
- Seeds do not preserve splits across changing order/software; raw rows may need stable identifiers.
Audit hardcoded platform paths when moving a notebook
Conditions
- code is moving from Kaggle to another environment
Action
- Proposed recipe: replace platform-specific data and output paths with explicit configuration.
Check
- Proposed check: Configure input/output roots, validate every required path, and run a small local inference fixture with a different working directory.
Limits
- Path replacement alone may leave dependency or device assumptions; source guidance is not a verified migration.
Encode checkpoint identity in inference artifacts
Conditions
- inference locates architectures and folds through checkpoint names
Action
- Proposed conditional application: Preserve architecture, fold, resolution and epoch in the selected checkpoint file names and separate binary/multiclass artifacts.
Check
- Proposed check: Inventory selected checkpoints with architecture/fold/resolution/epoch and hashes, validate loader selection, and perform a small inference restoration check.
Limits
- Filename conventions alone cannot establish checkpoint integrity; the Python2/CUDA/Keras patch is historical installation guidance.
Preserve the generating configuration with every prediction artifact
Conditions
- the best competition prediction cannot be regenerated
Action
- Proposed conditional application: Save configuration, data split, seed and prediction artifacts together.
Check
- Proposed check: Store config, split, seed, code/data hashes and predictions together, then regenerate a selected artifact from its manifest.
Limits
- Preserved prediction files alone cannot establish reproducibility; source's seed fishing contaminates test selection and is not recommended.
Record leaderboard-driven fold selection as a reproduction condition
Conditions
- reproducing a selected-fold ensemble
Action
- Proposed adaptation of source observation: Record the original fold artifact and fold selection rule alongside weights and compare with an all-fold baseline.
Check
- Proposed verification: Evaluate selection on an untouched holdout and verify exact fold IDs before claiming reproduction.
Limits
- Leaderboard selection can bias an ensemble; the README does not isolate its gain.
Verify architecture headings against executable configuration
Conditions
- reproduction instructions contain copied model-training blocks
Action
- Proposed adaptation of source observation: Resolve heading-versus-configuration disagreements against saved checkpoints and actual training records.
Check
- Proposed verification: Log the instantiated architecture and weight source before a reproduction run.
Limits
- The inconsistency is directly visible; the packet does not establish which configuration actually produced the table’s ConvNeXt scores.
Preserve supplied folds for reproducibility
Conditions
- a competition repository allows regeneration of fold assignments
Action
- Proposed: reuse the recorded folds for reproduction and treat regenerated folds as a separate experiment.
Check
- Proposed: hash and archive fold assignments; repeat the same experiment with fixed assignments before comparing model changes.
Limits
- Authors advise preserving their supplied fold files because regeneration changes results. No split-quality comparison is reported; hashes and assignment checks are proposed.
Store experiment code and prediction artifacts before ensemble search
Conditions
- many training runs feed later blending or deployment experiments
Action
- Save each run’s code, configuration, model, and row-aligned OOF/test predictions before ensemble search.
Check
- Reload a saved artifact and verify row/class/fold alignment against the recorded run.
Limits
- Incomplete distillation is a separate attempted experiment; the source establishes no successful student model.
Preserve notebook behavior when modularizing training
Conditions
- a competition notebook is converted into a maintained pipeline
Action
- Proposed conditional application: Separate loading, feature engineering, preprocessing and modeling while preserving seeds, configuration and original notebook artifacts.
Check
- Proposed check: Freeze inputs and splits, compare notebook and modular pipeline features, predictions and metrics; save configuration and seeds with discrepancies.
Limits
- Fixed seeds alone do not guarantee deterministic behavior across platforms.
- Published structure and README assertions do not establish execution, scaling or deployment readiness.
Reconcile sequence-length experiment records before reproducing an ensemble
Conditions
- reported text-ensemble configuration conflicts with its result table
Action
- Proposed adaptation of source observation: Treat sequence length as unresolved and independently compare both lengths under identical settings.
Check
- Proposed verification: Verify the saved configuration/checkpoint and assess accuracy/runtime versus truncation.
Limits
- The packet cannot establish which length achieved the final result; do not silently choose one.
- The author-reported 78.2% versus 78.6% length comparison has unspecified evaluation partition and conflicts with the final length/result description; no causal sequence-length gain can be assigned to the winning run.
Standardize team environments and cache training-ready arrays
Conditions
- multiple collaborators train on a repeated landmark dataset
Action
- Proposed adaptation of source observation: Use a versioned shared environment and persist a checked training-ready representation.
Check
- Proposed verification: Compare environment manifests and benchmark data-loader throughput and sample equality.
Limits
- Container and cached-data versions must track preprocessing changes; the source gives no isolated speed figure.