PolicyEngine / PolicyEngine/microcosm

Sweep λ_L2 in the production US build: ESS-vs-accuracy frontier for the sparse L0+refit dataset

Open
#285 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
0
Forks
4
Avg merge
1d 3h
Merged PRs (30d)
94

Description

Goal

Determine whether a positive L2 concentration penalty improves the effective sample size of the production sparse dataset without trading off target accuracy — or, failing that, publish the measured ESS-vs-accuracy frontier as evidence for keeping λ_L2 = 0. This executes the future-work item from the L0 paper ("trace effective-sample-size vs. accuracy trade-offs by varying λ_L2 and max_weight_ratio").

Blocked by #284 / PR #283 — without the refit-stage threading, λ_L2 never touches the shipped weights.

Baseline (paper probe, uncapped)

records weighted loss within 10% ESS max weight
informed L0+refit 57,240 0.0474 91.5% 4,726 913,836
dense full 337,704 0.0507 91.8% 5,970

Step 0 — ground the baseline (~minutes)

Score the current production candidate's weights with the new effective_sample_size() before spending compute. The paper probe was uncapped, while the builder defaults to --max-weight-ratio 5.0 — the real production baseline may already be less concentrated than the table above.

Step 1 — primary grid, both stages (~6.5 h sequential)

Eight builds at λ_L2 ∈ {0, 1e-4, 3e-4, 1e-3, 3e-3, 1e-2, 3e-2, 1e-1} via --l2-lambda, everything else at production defaults (seed 0, 1,500 epochs, mass="conserve", cap 5.0, --l0-refit-lambda-share 0.8). Weight ratios are O(1), so the penalty term is O(λ) against a calibration loss of ~0.05 — the action should sit in 1e-3…1e-1; the outer points confirm the flat and over-regularized ends.

Mechanics:

  • Reuse --target-frame-checkpoint + the target-materialization cache so each point costs only the ~49-min calibrate stage.
  • Pass --skip-reform-validation --skip-demographics on grid points.
  • Each run's calibration_diagnostics.json (schema v4) now carries final_loss, fraction_within_10pct, effective_sample_size, realized_max_weight_ratio, top_1pct_weight_share, plus selection-stage provenance — the frontier reads straight off the artifacts. The builder writes diagnostics even when release gates fail, so over-regularized points still yield data.

Step 2 — stage attribution (~3–4 h)

At the 2 most interesting λ values from step 1, isolate where the penalty does its work:

  • selection-only: --l2-lambda x --refit-l2-lambda 0 — does penalizing which records get picked matter even with an unpenalized final fit?
  • refit-only: --l2-lambda 0 --refit-l2-lambda x — spreading the shipped weights on a fixed support.

Control: selection-stage L2 shifts the retained count away from ~57k. Record n_selected_households per run; if drift exceeds ~10%, re-tune --l0-refit-lambda-share to restore the count so comparisons stay clean.

Step 3 — finalists

For the 1–2 frontier winners: full builds with reform validation (JCT in-sample + OBBBA out-of-sample backtests) and rotated-fold holdout analysis. A regularizer's payoff may show up as better out-of-sample behavior even at slightly higher in-sample loss.

Decision rule

Adopt the largest λ_L2 whose weighted loss stays within tolerance of the λ=0 baseline (e.g., no worse than the dense benchmark's 0.0507, vs the sparse baseline 0.0474) while ESS improves materially. Otherwise keep λ_L2 = 0 and record the frontier in the paper's next revision.

Notes

  • Runs are manual CLI invocations of tools/build_us_fiscal_refresh_release.py on a machine with the build inputs (ledger facts artifact, base H5); there is no CI build pipeline.
  • A small driver script looping the builder over the grid and tabulating the frontier from the diagnostics JSONs is worth adding alongside the sweep (tools/).

🤖 Generated with Claude Code

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start only after #284 / PR #283 lands, then use tools/build_us_fiscal_refresh_release.py and the target-frame checkpoint/cache to score the current production candidate with effective_sample_size(). Run the specified --l2-lambda grid and inspect each calibration_diagnostics.json, including ESS, loss, accuracy, and weight-ratio fields. Done means publishing the measured ESS-vs-accuracy frontier, stage-attribution results, and the decision on whether to retain or change λ_L2 = 0.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.