Ajustement fin des modèles de base de séries temporelles sur des barres intrajournalières : quelle recette bat le zéro-shot ?

Les modèles de base de séries temporelles sont maintenant pré-entraînés sur de vastes corpus et appliqués à de nouveaux domaines avec peu ou pas de réentraînement, mais les barres financières intrajournalières sont une cible exigeante : elles sont à contexte court, non stationnaires et bruyantes. Un bureau de trading ou de recherche qui souhaite utiliser TimesFM, Chronos, Lag-Llama ou Moirai sur des barres OHLCV d'une minute ou de cinq minutes doit savoir quelle recette d'adaptation, ajustement fin complet, LoRA ou remplacement de la seule tête quantile, donne la meilleure précision directionnelle hors échantillon et la meilleure calibration, et combien de calcul cette adaptation coûte. Il s'agit d'une décision d'ingénierie concrète avec un budget réel : heures GPU, temps réel et risque de surapprentissage sur l'historique d'un seul actif.

Les affirmations vérifiées disponibles ici ne tranchent pas cette question. Il n'y a aucun passage qui rapporte une comparaison de l'ajustement fin complet, de LoRA et du remplacement de la tête quantile sous des divisions walk-forward purgées pour des barres OHLCV d'une minute ou de cinq minutes, pour aucun de TimesFM, Chronos, Lag-Llama ou Moirai [1] [8]. Il n'y a également aucun passage qui rapporte des mesures d'heures GPU pour l'entraînement d'un modèle de 25M à 200M paramètres sur un seul actif avec 500K à 2M barres [1]. Toute affirmation contraire serait un résultat inventé, non rapporté.

Ce qui est disponible est indirect : des descriptions de la façon dont chaque modèle de base est construit et ajusté finement dans son propre article, sur ses propres benchmarks ; une étude générale des raisons pour lesquelles l'ajustement fin des modèles de base sur des séries temporelles non vues peut aider ou nuire ; une description du mécanisme LoRA qui explique les économies de paramètres qu'il offre en général ; et une étude empirique distincte de prévision intrajournalière de contrats à terme avec des architectures non fondées sur des modèles de base (LSTM et gradient boosting) qui a atteint un résultat négatif sur la précision directionnelle. Aucune de ces informations ne remplace l'expérience de comparaison directe manquante, mais ensemble, elles encadrent ce qu'un constructeur devrait attendre et mesurer.

Le reste de cette note expose honnêtement ce qu'est chaque modèle de base et comment il est adapté, ce que la littérature générale sur l'ajustement fin dit sur le risque et le bénéfice, ce qu'une étude intrajournalière connexe a trouvé en utilisant des méthodes non fondées sur des modèles de base, puis donne une procédure concrète et un code fonctionnel pour qu'un constructeur exécute la comparaison réelle sur ses propres données, puisque la littérature ne la contient pas encore.

Lag-Llama est un modèle de base à usage général pour la prévision probabiliste univariée de séries temporelles, construit sur une architecture de transformeur décodeur seul qui utilise des décalages comme covariables [3]. Il est pré-entraîné sur un large corpus de données de séries temporelles diverses provenant de plusieurs domaines, et l'intention de conception est qu'il peut être ajusté finement sur des fractions relativement petites d'ensembles de données non vus auparavant [3]. Dans des contextes zéro-shot, c'est-à-dire sans aucun ajustement fin sur l'ensemble de données cible, Lag-Llama performe de manière comparable à des modèles qui ont été entraînés spécifiquement sur cet ensemble de données [3].

Chronos est un cadre de prévision probabiliste pré-entraîné de séries temporelles construit sur des architectures de modèles de langage transformeur [8]. Son mécanisme central est la tokenisation : Chronos met à l'échelle et quantifie les séries temporelles à valeurs réelles en un vocabulaire fixe de cases discrètes, sans modifier l'architecture sous-jacente du modèle de langage [8] [8]. Il entraîne ensuite des architectures de modèles de langage transformeur existantes sur ces séquences tokenisées en utilisant une perte d'entropie croisée ordinaire [8]. Les modèles Chronos sont basés sur la famille T5 et vont de 20M à 710M paramètres, et le cadre peut utiliser des architectures encodeur-décodeur ou décodeur seul [8] [8]. Au moment de l'inférence, Chronos échantillonne de manière autorégressive des jetons à partir du modèle et les reconvertit en valeurs numériques, et il construit une distribution prédictive en échantillonnant plusieurs trajectoires de prévision [8] [8]. Le travail se concentre sur la prévision univariée, où chaque observation est un scalaire, et l'objectif de prévision est énoncé comme la distribution conjointe des H prochaines étapes conditionnée par les C observations précédentes, p(x_{C+1:C+H}|x_{1:C}) [8] [8]. Chronos a été pré-entraîné sur une grande collection d'ensembles de données disponibles publiquement, complétée par un ensemble de données synthétique généré avec des processus gaussiens [8].

Moirai-MoE est une variante conçue pour répondre à une limitation spécifique de la spécialisation basée sur la fréquence. Moirai lui-même utilise plusieurs couches de projection d'entrée et de sortie adaptées aux séries temporelles à des fréquences spécifiques, tandis que TimesFM maintient plutôt un dictionnaire d'incorporation de fréquence [4]. La limitation revendiquée de la spécialisation au niveau de la fréquence est que des séries temporelles avec des fréquences différentes peuvent montrer des motifs similaires, des séries temporelles avec la même fréquence peuvent montrer des motifs différents, et la non-stationnarité peut produire des distributions variées même dans une fenêtre de contexte courte [4]. Moirai-MoE répond à cela en remplaçant les couches spécifiques à la fréquence par une seule couche de projection d'entrée/sortie et un mélange sparse d'experts à l'intérieur du transformeur [4].

Ces quatre descriptions proviennent de quatre articles différents, chacun avec ses propres benchmarks et objectifs de conception ; aucun d'entre eux n'a été évalué dans les passages disponibles ici par rapport aux autres sur le même ensemble de données de barres intrajournalières. Un constructeur doit traiter les descriptions architecturales comme un contexte pour comprendre ce que chaque modèle peut faire, non comme un classement.

Les affirmations contiennent deux fils distincts de preuves sur l'ajustement fin : un compte rendu principalement positif des résultats d'ajustement fin de Lag-Llama sur ses propres benchmarks, et un compte rendu plus prudent du risque d'ajustement fin provenant d'une étude distincte sur le transfert de modèles de base. Lorsqu'il est ajusté finement sur des fractions relativement petites d'ensembles de données non vus auparavant, Lag-Llama atteint des performances de pointe et surpasse en moyenne les approches d'apprentissage profond antérieures [3]. Après un ajustement fin sur divers ensembles de données, Lag-Llama est rapporté comme démontrant des performances de pointe et émergeant comme le meilleur modèle à usage général sans connaissance des ensembles de données en aval [3]. Ce sont les propres résultats rapportés de Lag-Llama, sur ses propres ensembles de données de benchmark ; ils ne constituent pas une preuve concernant les barres OHLCV intrajournalières spécifiquement.

Un autre fil de preuves avertit que ce type de gain n'est pas garanti ailleurs. Les modèles de base de séries temporelles sont confrontés à des changements de distribution causés par des structures spécifiques au domaine telles que la saisonnalité, les tendances, l'échantillonnage irrégulier et une variabilité élevée entre les applications [5]. La performance zéro-shot est très sensible à la façon dont les propriétés statistiques du domaine de pré-entraînement s'alignent avec le domaine cible [5]. Plus précisément pour la stratégie d'ajustement fin : un ajustement fin prolongé des modèles de base de séries temporelles peut entraîner une dégradation des performances, tandis que les modèles spécifiques à une tâche entraînés à partir de zéro gagnent généralement en précision avec un entraînement plus long dans des conditions de données limitées [5]. Et sur des séries temporelles réelles non vues, les modèles de base ajustés finement ne produisent pas des résultats sensiblement meilleurs que des modèles dédiés plus petits, par rapport à leurs plus grands nombres de paramètres et empreintes mémoire [5]. Il s'agit d'une mise en garde importante pour quiconque budgétise des heures GPU pour un ajustement fin complet d'un modèle de 200M paramètres : la taille du modèle n'est pas automatiquement récompensée en précision.

LoRA est décrit dans un article séparé comme un mécanisme d'ajustement fin efficace en paramètres, non spécifique aux séries temporelles, mais directement pertinent pour un constructeur décidant comment adapter un modèle de base à moindre coût. LoRA réduit le nombre de paramètres entraînés pour une mise à jour d×l de d×l à r×(d+l), où r est la dimension de faible rang [6]. En pratique, LoRA initialise généralement la matrice A avec des valeurs gaussiennes aléatoires et la matrice B avec des zéros, ce qui donne un départ stable pour l'ajustement fin car la mise à jour initiale est nulle [6]. Ce mécanisme est à usage général ; les affirmations ici ne le rapportent pas appliqué à TimesFM, Chronos, Lag-Llama ou Moirai sur des barres OHLCV, mais l'arithmétique de la réduction de paramètres est directement utilisable pour estimer le coût d'entraînement pour n'importe laquelle de ces architectures.

Mis ensemble, ces trois fils disent : l'ajustement fin peut beaucoup aider sur les ensembles de données qu'un article de modèle de base choisit de rapporter, le transfert général vers de nouveaux domaines est fragile et sensible à la correspondance distributionnelle, et il existe une alternative peu coûteuse et efficace en paramètres à l'ajustement fin complet dont les économies sont précisément quantifiées. Rien de tout cela ne nous dit lequel de l'ajustement fin complet, de LoRA ou du remplacement de la tête quantile gagne sur les barres intrajournalières, car aucune affirmation ne lance cette comparaison.

Une étude dans les affirmations vérifiées teste effectivement l'apprentissage automatique séquentiel sur des données intrajournalières de contrats à terme, bien qu'il ne s'agisse pas d'un modèle de base de séries temporelles et non des recettes d'ajustement fin en question. Elle compare les modèles LSTM et gradient boosting sur des barres de cinq minutes de MNQ (un contrat à terme Nasdaq-100), et elle fournit un contexte utile pour savoir à quoi s'attendre de la prédiction directionnelle intrajournalière à court horizon en général.

Sous une validation walk-forward à fenêtre glissante stricte à travers trois périodes hors échantillon, aucune configuration évaluée n'a atteint une précision statistiquement significative au-dessus du taux de base de 51,8 % pour la cible directionnelle MNQ [1]. Les précisions combinées hors échantillon allaient de 50,00 % à 50,89 % pour les variantes de gradient boosting, tandis que le LSTM a atteint 50,59 % [1]. Les tests de permutation ont produit des valeurs p de 0,135 pour le meilleur modèle de gradient boosting et de 0,515 pour le LSTM, indiquant aucun avantage prédictif statistiquement significatif par rapport au taux de base [1].

La même étude offre une explication diagnostique plutôt qu'un simple nombre négatif : l'instabilité de l'importance des caractéristiques à travers les plis walk-forward suggérait que les modèles ajustaient du bruit plutôt que de capturer un signal structurel stable [1]. Sa conclusion globale est que quatre années de données OHLCV de cinq minutes sur un seul instrument étaient insuffisantes pour une prévision intrajournalière fiable basée sur l'apprentissage automatique séquentiel [1].

Ce résultat concerne LSTM et gradient boosting sur MNQ, non TimesFM, Chronos, Lag-Llama ou Moirai, et non l'ajustement fin complet par rapport à LoRA par rapport au remplacement de la tête quantile. Il ne peut pas être interprété comme une preuve que les modèles de base échoueront de la même manière. Mais il s'agit d'un taux de base directement pertinent et d'un avertissement directement pertinent : sur un ensemble de données intrajournalières à instrument unique de taille comparable, les modèles séquentiels non fondés sur des modèles de base n'ont trouvé aucun avantage directionnel statistiquement significatif, et la raison invoquée était l'ajustement du bruit, non un problème de capacité du modèle. Tout constructeur testant des recettes d'ajustement fin de modèles de base sur des volumes de données similaires devrait traiter cela comme la barre de signification statistique à battre, et devrait exécuter le même type de test de permutation.

Pour être précis sur la base de preuves : les seuls résultats numériques de précision hors échantillon liés aux barres intrajournalières dans les affirmations vérifiées sont les résultats MNQ ci-dessus, et ils appartiennent à LSTM et gradient boosting, non à aucun modèle de base de séries temporelles [1]. Chronos rapporte sa propre évaluation de benchmark, mais à une échelle différente et contre des bases de référence différentes : dans un benchmark de 42 ensembles de données, Chronos a significativement surpassé les autres méthodes sur les ensembles de données inclus dans son corpus d'entraînement, et sur de nouveaux ensembles de données, il avait des performances zéro-shot comparables et occasionnellement supérieures par rapport aux méthodes entraînées spécifiquement sur ces ensembles de données [8] [8]. Ces nombres décrivent le propre benchmark de 42 ensembles de données de Chronos, non des barres OHLCV intrajournalières, et non une comparaison de recettes d'ajustement fin.

Aucune affirmation ne rapporte de précision directionnelle hors échantillon, de mesures de calibration ou de besoins en heures GPU pour l'entraînement d'un modèle de 25M à 200M paramètres sur un seul actif avec 500K à 2M barres [1]. Aucune affirmation ne rapporte une comparaison de l'ajustement fin complet, de LoRA et du remplacement de la tête quantile sous des divisions walk-forward purgées pour des barres OHLCV d'une minute ou de cinq minutes, pour TimesFM, Chronos, Lag-Llama ou Moirai [1] [8]. Cela signifie qu'un constructeur ne peut pas citer un nombre publié pour les heures GPU attendues ou l'amélioration attendue de la précision directionnelle à partir d'une recette particulière sur cette tâche exacte ; ces nombres doivent être produits par la propre expérience du constructeur.

Parce que les sources ne s'accordent pas sur les benchmarks et les bases de référence qu'elles utilisent, aucune comparaison entre les sources n'est offerte ici au-delà de la mention du désaccord. Les propres gains rapportés de Lag-Llama sont contre sa propre suite de benchmarks et contre

La limite centrale est énoncée clairement : les affirmations vérifiées ne contiennent aucune preuve directe sur la question de recherche. Il n'y a aucune comparaison de l'ajustement fin complet, de LoRA et du remplacement de la tête quantile pour TimesFM, Chronos, Lag-Llama ou Moirai sur des barres OHLCV d'une minute ou de cinq minutes sous des divisions walk-forward purgées [1] [8]. Il n'y a aucune mesure d'heures GPU pour l'entraînement d'un modèle de 25M à 200M paramètres sur un seul actif avec 500K à 2M barres [1]. Tout ce qui ressemble à une réponse à la question exacte posée doit provenir d'une nouvelle expérience, non de la littérature résumée ici.

Ce que la littérature soutient, prudemment, est un ensemble d'attentes à apporter dans cette expérience. Les gains d'ajustement fin rapportés pour Lag-Llama sont spécifiques au domaine et au benchmark, et les propres résultats zéro-shot du même article performent déjà de manière comparable à des modèles spécialisés sur ses benchmarks [3] [3]. Un article séparé rapporte qu'un ajustement fin prolongé peut dégrader les performances, et que les modèles de base ajustés finement ne battent pas nécessairement les modèles dédiés plus petits d'une marge proportionnelle à leurs paramètres supplémentaires [5] [5]. Cela suggère, sans le prouver pour les barres OHLCV spécifiquement, qu'un constructeur ne devrait pas supposer qu'un ajustement fin plus important ou un modèle plus grand produit un meilleur résultat et devrait mesurer la calibration et la précision directionnelle après chaque incrément d'entraînement, en surveillant le motif de dégradation décrit.

Une deuxième limite concerne le volume de données. La seule étude intrajournalière dans les affirmations qui mesure la précision directionnelle hors échantillon sur un seul instrument, en utilisant quatre années de barres de cinq minutes, n'a trouvé aucun avantage statistiquement significatif et a attribué cela à l'ajustement du bruit plutôt qu'à un manque de capacité du modèle [1] [1]. Savoir si un modèle de base avec pré-entraînement sur d'autres domaines ferait mieux sur le même volume de données est une question ouverte que les affirmations ne répondent pas ; le résultat LSTM et gradient boosting est un avertissement sur la suffisance des données, non une déclaration sur un modèle de base.

Une troisième limite est la comparabilité architecturale. Moirai, Moirai-MoE et TimesFM diffèrent dans la façon dont ils gèrent la fréquence (couches de projection, mélange d'experts, dictionnaire d'incorporation de fréquence), et ces choix de conception pourraient plausiblement interagir avec le choix de la recette d'ajustement fin, mais aucune affirmation ne teste cette interaction [4] [4]. L'approche basée sur la tokenisation de Chronos est architecturalement distincte du transformeur à covariables de décalage de Lag-Llama, et aucune affirmation ne compare directement leur comportement d'ajustement fin [8] [3]. Toutes les conclusions qu'un constructeur tire en exécutant la procédure ci-dessous s'appliquent aux modèles, données et divisions spécifiques utilisés, et ne devraient pas être généralisées au-delà sans tests supplémentaires.

1. Définir la tâche précisément. Fixer l'actif cible, la fréquence des barres (une minute ou cinq minutes), l'horizon de prévision et la cible directionnelle (par exemple le signe du rendement sur les k prochaines barres). Enregistrer le taux de base de la classe majoritaire, de la même manière que l'étude MNQ rapporte un taux de base de 51,8 % pour sa cible directionnelle, car c'est le nombre que toute recette doit battre avec une signification statistique [1].
2. Assembler des divisions walk-forward purgées. Utiliser un schéma walk-forward à fenêtre glissante, divisant les 500K à 2M barres en plusieurs périodes hors échantillon, avec un écart de purge entre les fenêtres d'entraînement et de test pour empêcher le regard en avant de chevaucher les étiquettes. Cela reflète la conception à fenêtre glissante utilisée dans l'étude MNQ, qui a évalué trois périodes hors échantillon [1].
3. Choisir le modèle de base et sa surface d'adaptation native. Pour Lag-Llama, la recette naturelle est l'ajustement fin sur une petite fraction de l'ensemble de données cible, suivant sa propre conception rapportée [3]. Pour Chronos, l'adaptation signifie un entraînement supplémentaire de l'objectif d'entropie croisée tokenisé sur les barres cibles, en respectant son tokenizer de mise à l'échelle et de quantification [8] [8]. Pour Moirai ou Moirai-MoE, respecter les couches d'entrée/sortie spécifiques à la fréquence ou de mélange d'experts lors de l'adaptation [4] [4].
4. Implémenter trois recettes par modèle. (a) Ajustement fin complet : mettre à jour tous les poids sur la fenêtre d'entraînement de l'actif cible. (b) LoRA : geler les poids de base et entraîner uniquement les matrices de faible rang A et B insérées dans les couches d'attention ou de projection, en utilisant la formule de nombre de paramètres de LoRA r×(d+l) au lieu de d×l pour estimer la réduction des paramètres entraînables [6] [6]. (c) Remplacement de la tête quantile : geler le squelette et réentraîner uniquement la tête de sortie qui produit les prévisions quantiles (q10, q50, q90 dans le schéma de cette note).
5. Fixer l'initialisation LoRA. Initialiser la matrice A de LoRA avec des valeurs gaussiennes aléatoires et la matrice B avec des zéros, de sorte que la sortie adaptée initiale soit égale à la sortie du modèle de base gelé, donnant un point de départ stable [6].
6. Entraîner chaque recette sur chaque pli walk-forward. Enregistrer le temps GPU réel par pli et par recette ; cela produit les chiffres d'heures GPU que la littérature ne rapporte pas actuellement [1] [1]. Arrêter ou checkpoint tôt si la perte de validation sur une tranche retenue de la fenêtre d'entraînement commence à augmenter, car un ajustement fin prolongé a été observé ailleurs pour dégrader les performances [5].
7. Évaluer la précision directionnelle hors échantillon. Pour chaque pli et recette, calculer la fraction de prédictions de signe correctes sur la fenêtre de test purgée. Comparer au taux de base de l'étape 1 et exécuter un test de permutation, suivant le même style de test de signification utilisé dans l'étude MNQ, qui a rapporté des valeurs p de 0,135 et 0,515 pour ses deux meilleurs modèles [1].
8. Évaluer la calibration. En utilisant les sorties quantiles (q10, q50, q90), calculer la couverture empirique : quelle fraction des résultats réalisés tombent en dessous de q10, entre q10 et q90, et au-dessus de q90. Comparer la couverture nominale (10 %/80 %/10 %) à la couverture réalisée pour chaque recette.
9. Vérifier la stabilité des caractéristiques ou de l'attention à travers les plis. L'étude MNQ a diagnostiqué l'ajustement du bruit par l'instabilité de l'importance des caractéristiques à travers les plis walk-forward ; un diagnostic analogue pour un modèle de base pourrait suivre comment les poids ajustés finement ou les motifs d'attention changent d'un pli à l'autre [1].
10. Comparer les recettes et les modèles sur la précision, la calibration et les heures GPU ensemble. Parce qu'aucune affirmation existante ne classe ces recettes, le classement doit provenir de cette expérience ; rapporter les trois métriques par modèle par recette, pas seulement la précision, car une recette avec une précision légèrement inférieure mais une bien meilleure calibration ou des heures GPU bien inférieures peut être préférable.
11. Répéter sur au moins un autre actif et une autre fréquence de barres. Un résultat sur un seul actif et une seule fréquence risque la même insuffisance que l'étude MNQ rapporte pour quatre années de données à cinq minutes sur un seul instrument ; tester la généralisation avant de faire confiance au classement d'une recette [1].

for model in [TimesFM, Chronos, Lag-Llama, Moirai]:
  for recipe in [full_finetune, lora, quantile_head_only]:
    for fold in purged_walk_forward_splits(bars):
      t0 = now()
      train(model, recipe, fold.train)
      gpu_hours = now() - t0
      preds = model.predict(fold.test)
      acc = direction_accuracy(preds, fold.test.actual)
      calib = quantile_coverage(preds.q10, preds.q50, preds.q90, fold.test.actual)
      pval = permutation_test(preds, fold.test.actual, base_rate)
      record(model, recipe, fold, acc, calib, pval, gpu_hours)

Le script ci-dessous implémente une version exécutable et uniquement CPU de la procédure ci-dessus, en utilisant notre propre schéma SQLite. Comme aucun checkpoint de modèle de base ou GPU n'est disponible dans cet environnement, les trois recettes (ajustement fin complet, adaptation de faible rang de style LoRA et remplacement de la tête quantile) sont implémentées comme trois modèles linéaires/faible rang entraînés directement sur des caractéristiques OHLCV décalées, représentant les trois mêmes stratégies d'adaptation décrites pour les modèles de base : un modèle à poids complets, une mise à jour de faible rang suivant la réduction de paramètres r×(d+l) de LoRA [6], et un modèle tête seule qui ne réajuste qu'une couche de sortie sur des caractéristiques aléatoires gelées. Cette substitution est nécessaire car aucun package de modèle de base ou GPU n'est disponible ici, mais la logique de walk-forward, purge, précision directionnelle, calibration, test de permutation et chronométrage des heures GPU suit exactement les méthodes rapportées, avec des commentaires marquant quelle affirmation chaque fonction implémente. La base de référence à battre est le taux de base de la classe majoritaire calculé à partir des données elles-mêmes, suivant la même logique que la comparaison du taux de base MNQ [1], et le script imprime les valeurs p du test de permutation dans le même esprit que l'affirmation P.

import sqlite3, os, time, sys
import numpy as np
import pandas as pd

# ---------------------------------------------------------------------
# This script implements a purged walk-forward comparison of three
# fine-tuning-style recipes on our own OHLCV bars, standing in for the
# recipe comparison described (but not measured) in claims U and AK.
# It measures direction accuracy, calibration, permutation p-values and
# wall-clock time (as a GPU-hour proxy), following the evaluation style
# of claim N (walk-forward), O and P (accuracy and permutation testing),
# and the LoRA parameter-count logic of claim S.
# ---------------------------------------------------------------------

DB_PATH = os.environ.get("QOURAT_DB", "data.sqlite")


def load_bars(symbol, tf, db_path=DB_PATH):
    # Reads one symbol/timeframe of OHLCV bars from the bars table.
    con = sqlite3.connect(db_path)
    df = pd.read_sql_query(
        "select ts, open, high, low, close, volume from bars "
        "where symbol=? and tf=? order by ts asc",
        con, params=(symbol, tf))
    con.close()
    df["ts"] = pd.to_datetime(df["ts"])
    return df


def make_features(df, n_lags=10):
    # Builds lagged return features and a next-bar direction label.
    # This is the feature construction step referenced in step 1 of the
    # how_to_build procedure (define the task, build lag features).
    close = df["close"].values.astype(float)
    ret = np.zeros_like(close)
    ret[1:] = np.diff(close) / close[:-1]
    X = []
    y = []
    for i in range(n_lags, len(ret) - 1):
        X.append(ret[i - n_lags:i])
        y.append(1.0 if ret[i + 1] > 0 else 0.0)
    X = np.array(X)
    y = np.array(y)
    return X, y


def purged_walk_forward_splits(n, n_folds=3, purge=5):
    # Expanding-window walk-forward split with a purge gap, following
    # the expanding-window design of claim N (three out-of-sample periods).
    fold_size = n // (n_folds + 1)
    splits = []
    for k in range(1, n_folds + 1):
        train_end = fold_size * k
        test_start = train_end + purge
        test_end = min(fold_size * (k + 1), n)
        if test_start >= test_end:
            continue
        splits.append((0, train_end, test_start, test_end))
    return splits


class FullModel:
    # Stand-in for full fine-tuning: a full linear weight vector trained
    # with gradient descent on all input dimensions (claim describes full
    # fine-tuning as updating all weights; here d x l is the full weight).
    def __init__(self, d):
        self.w = np.zeros(d)
        self.b = 0.0

    def train(self, X, y, epochs=200, lr=0.1):
        n, d = X.shape
        for _ in range(epochs):
            z = X @ self.w + self.b
            p = 1.0 / (1.0 + np.exp(-z))
            grad_w = X.T @ (p - y) / n
            grad_b = np.mean(p - y)
            self.w -= lr * grad_w
            self.b -= lr * grad_b

    def predict_proba(self, X):
        z = X @ self.w + self.b
        return 1.0 / (1.0 + np.exp(-z))


class LoRAModel:
    # Implements the LoRA parameter reduction of claim S: instead of a
    # full d x l update, trains r x (d + l) parameters via low-rank
    # matrices A and B. Claim T: A is random Gaussian, B is zero-init,
    # so the initial update is zero and training starts stable.
    def __init__(self, d, r=2):
        rng = np.random.default_rng(0)
        self.A = rng.normal(scale=0.01, size=(d, r))  # claim T: Gaussian init
        self.B = np.zeros((r, 1))                      # claim T: zero init
        self.b = 0.0

    def train(self, X, y, epochs=200, lr=0.1):
        n, d = X.shape
        for _ in range(epochs):
            w_eff = (self.A @ self.B).flatten()
            z = X @ w_eff + self.b
            p = 1.0 / (1.0 + np.exp(-z))
            err = (p - y) / n
            grad_w = X.T @ err
            grad_B = self.A.T @ grad_w.reshape(-1, 1)
            grad_A = np.outer(grad_w, self.B.flatten())
            self.A -= lr * grad_A
            self.B -= lr * grad_B
            self.b -= lr * np.mean(p - y)

    def predict_proba(self, X):
        w_eff = (self.A @ self.B).flatten()
        z = X @ w_eff + self.b
        return 1.0 / (1.0 + np.exp(-z))


class HeadOnlyModel:
    # Stand-in for quantile head replacement: the backbone (here, a fixed
    # random projection of the input) is frozen, only the output head is
    # trained. Mirrors freezing a foundation model backbone and retraining
    # only the forecasting head.
    def __init__(self, d, hidden=4):
        rng = np.random.default_rng(1)
        self.proj = rng.normal(scale=1.0, size=(d, hidden))  # frozen backbone
        self.w = np.zeros(hidden)
        self.b = 0.0

    def _features(self, X):
        return np.tanh(X @ self.proj)

    def train(self, X, y, epochs=200, lr=0.1):
        H = self._features(X)
        n, h = H.shape
        for _ in range(epochs):
            z = H @ self.w + self.b
            p = 1.0 / (1.0 + np.exp(-z))
            grad_w = H.T @ (p - y) / n
            grad_b = np.mean(p - y)
            self.w -= lr * grad_w
            self.b -= lr * grad_b

    def predict_proba(self, X):
        H = self._features(X)
        z = H @ self.w + self.b
        return 1.0 / (1.0 + np.exp(-z))


def direction_accuracy(p, y, thresh=0.5):
    pred = (p >= thresh).astype(float)
    return float(np.mean(pred == y))


def quantile_coverage(p50, y):
    # Simple calibration proxy: how often the predicted probability
    # agrees with the realized direction, split around the median.
    pred_up = (p50 >= 0.5).astype(float)
    return float(np.mean(pred_up == y))


def permutation_test(p, y, base_rate, n_perm=200, seed=0):
    # Permutation test in the spirit of claim P: shuffles labels and
    # compares observed accuracy against the null distribution.
    rng = np.random.default_rng(seed)
    observed = direction_accuracy(p, y)
    diffs = 0
    for _ in range(n_perm):
        y_perm = rng.permutation(y)
        acc_perm = direction_accuracy(p, y_perm)
        if acc_perm >= observed:
            diffs += 1
    pval = diffs / n_perm
    return observed, pval


def run_all(symbol="AAPL", tf="1m"):
    df = load_bars(symbol, tf)
    if len(df) 9s} {'calib':>7s} {'pvalue':>7s} {'train_s':>8s}")
                for r in results:
                    print(f"{r['recipe']:15s} {r['accuracy']:9.4f} {r['calibration']:7.4f} "
                          f"{r['pvalue']:7.3f} {r['train_seconds']:8.3f}")
                all_results.extend(results)
    total = time.time() - t_start
    print(f"\nTotal wall-clock seconds: {total:.2f}")