Meta-score v2 — regime i cohort features

2026-05-15 nalaz

Pet novih cohort feature-a diže regime_cycle sa AUC 0.377 na 0.557 i menja znak spread-a. Najjača težina je btc_trend — model kažnjava kasne ulaske.

↑ Svi izveštaji ← Pun backfill sa novim BB generatorima Live-tick audit →

Date: 2026-05-15. Adds 5 cohort/regime features on top of the original 12 per-symbol-per-candle features (memory s5 said this was the highest-leverage research step).

What was added

Five new feature columns in src.meta_score.DEFAULT_FEATURE_COLUMNS:

Feature	Definition
`btc_ret_pct`	BTC's own 1-candle return % at signal close
`btc_trend`	`btc_close / btc_ema_fast - 1` (BTC short-term trend strength)
`alt_minus_btc_trend`	`close_over_ema_fast - btc_trend` (alt strength vs BTC)
`regime_is_trending`	1.0 when BTC regime ∈ {trending_lowvol, trending_highvol}
`regime_is_highvol`	1.0 when BTC regime ∈ {trending_highvol, ranging_highvol}

btc_close / btc_ema_fast had been in the features schema since IMPROVEMENT_PLAN A.5 but were never populated — build_features_cache.py did not load BTCUSDT klines. Fixed: BTCUSDT 4h klines added (804 rows) and build_features_cache.build_all now merges BTC per timeframe. 73930 4h feature rows re-emitted with btc_close populated.

regime_is_* come from src.regime.classify_regimes over BTCUSDT 4h features (749 valid rows, 55 warm-up). Backfilled into the regimes table for the first time.

build_training_set now joins the regime label per-trade at entry time from the regimes table.

Headline result

Walk-forward AUC over the prod backup crypto_scanner_prod_20260509_safe.db:

Generator	v1 AUC	v2 AUC	Δ	v1 spread	v2 spread
`growth_threshold_regime_cycle`	0.377	0.557	+0.180	−0.20	+0.20
`growth_threshold_quality_cycle_v2`	0.415	0.362	−0.053	−0.20	−0.22
`growth_threshold_cycle`	0.515	0.512	−0.003	+0.02	+0.02

regime_cycle crosses the 0.55 threshold for the first time. Top-bottom quartile spread sign-flips from −0.20 to +0.20 — the v2 model now actually ranks winners above losers (instead of below, as v1 did).

Other two:

qcv2 got worse. 90 trades is too few for a 17-feature model — the added features overfit. v1 was already shaky (−0.20 spread); v2 just adds noise.
gtc unchanged. 6941 trades, AUC pinned near 0.5 across both feature sets. The workhorse's structural problem (slot saturation by dud signals) is not a per-entry classification problem.

regime_cycle feature weights (standardized)

btc_trend             -0.155   ← strongest signal
taker_buy_ratio       +0.089
rsi                   -0.074
btc_ret_pct           -0.063
plus_di               -0.060
atr                   -0.060
regime_is_highvol     -0.056
adx                   +0.041
alt_minus_btc_trend   +0.037
close_over_ema_fast   -0.032
...
intercept:            -0.786

Interpretation: regime_cycle entries win MORE when:

BTC is NOT in a strong short-term uptrend (btc_trend neg coef)
Taker-buy ratio is elevated (real bid pressure, +)
RSI is lower (no late-rally chase, −)
The current candle is NOT high-volatility regime (− on regime_is_highvol)

Consistent with the generator's design: it targets reversal / cycle inflections, not continuation. Per-symbol features alone could not encode "BTC isn't in a runaway move" — the cohort feature carries it.

Caveats

41 usable trades for regime_cycle. Walk-forward AUC 0.557 has a wide confidence interval — could be 0.45-0.65 with 95% CI. Treat as promising hypothesis, not promotion criterion.
The v2 → v1 spread sign-flip on the same 41 trades suggests the new features actually add information rather than just retrofitting noise, but the sample is small enough that a 3-6 month re-test is essential before relying on it for live ranking.
qcv2 regression is informative: cohort features are NOT a free win; they add complexity that can hurt low-N generators.

Files

Models: models/regime_cycle_v2.json, models/qcv2_v2.json, models/gtc_v2.json
Slim reports: reports/analysis/meta_score_{regime_cycle,qcv2,gtc}_v2.json
Schema changes: src/meta_score.py (DEFAULT_FEATURE_COLUMNS, _augment, build_training_set regime lookup)
Feature pipeline: tools/history_cache/build_features_cache.py now merges BTCUSDT klines for every alt symbol's features cache.

Reproduce

# 1) Make sure BTCUSDT 4h klines are in the cache
.venv39/Scripts/python.exe -m tools.history_cache.build_klines_cache `
  --interval 4h --start 2026-01-01 --symbols BTCUSDT

# 2) Rebuild 4h features with BTC merge (97 symbols, ~30s)
.venv39/Scripts/python.exe -c "
import sqlite3, sys; sys.path.insert(0, '.')
from datetime import datetime
from tools.history_cache.build_features_cache import build_one, _load_klines
from src import feature_store as fs
conn = sqlite3.connect('database/klines_cache.db')
fs.ensure_features_schema(conn)
since = datetime(2026, 1, 1)
since_ms = int((since - datetime(1970, 1, 1)).total_seconds() * 1000)
btc = _load_klines(conn, 'BTCUSDT', '4h', since_ms)
for s in [r[0] for r in conn.execute(\"SELECT DISTINCT symbol FROM klines WHERE interval='4h'\").fetchall()]:
    build_one(conn, s, '4h', since=since, btc_klines=btc if not btc.empty else None)
"

# 3) Backfill regimes for BTCUSDT 4h
.venv39/Scripts/python.exe -c "
import sqlite3, sys; sys.path.insert(0, '.')
from src import feature_store as fs, regime as rg
conn = sqlite3.connect('database/klines_cache.db')
btc = fs.get_features(conn, 'BTCUSDT', '4h')
rg.persist_regimes(conn, rg.classify_regimes(btc), symbol='BTCUSDT', timeframe='4h')
"

# 4) Retrain meta-score
$env:DATABASE_URL = 'sqlite:///E:/Work/AI/opencodeTest/crypto_scanner/database/crypto_scanner_prod_20260509_safe.db'
.venv39/Scripts/python.exe -m tools.analysis.train_meta_score `
  --generator growth_threshold_regime_cycle `
  --report-json reports/analysis/meta_score_regime_cycle_v2.json `
  --out models/regime_cycle_v2.json

Izvor: crypto_scanner/reports/analysis/2026-05-15_meta_score_v2_regime_cohort.md