Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 28 octobre 2026.

En bref

Comprendre quel historique alimente une prévision et jusqu’où elle porte aide à comparer les modèles avant d’en choisir un. Dans TW3Cast, prépublication déposée sur arXiv le 16 septembre 2026, les auteurs décrivent comment préparer les données passées et produire les valeurs à venir. Le code de TW3 Partners du 21 septembre 2026 conserve d’abord au plus les 8 192 dernières valeurs observées, puis adapte cet historique avant le calcul. Pour prévoir plus loin, certaines fonctions avancent par étapes en réutilisant leurs propres prévisions. Dans leur réponse publique du 21 septembre 2026, les auteurs précisent que certains résultats soumis à l’évaluation reposent sur des réglages différents de ceux du code public.

1. Quelle différence entre contexte, fréquence et horizon ?

Le contexte est l’historique fourni, la fréquence indique la cadence d’observation et l’horizon est la longueur de la prévision attendue. Ces paramètres décrivent des aspects distincts de la demande adressée au modèle.

Dans TW3Cast de TW3 Partners du 16 septembre 2026, les configurations sont définies par le jeu de données, la fréquence et la classe d’horizon. L’annexe donne notamment la clé electricity/H/long. Son dernier terme indique une classe ; il faut encore lire les règles du benchmark pour connaître le nombre de valeurs à produire.

Le code GIFT-Eval de Salesforce, révision 577a65c examinée le 9 octobre 2026, associe une longueur de base à la fréquence. La propriété prediction_length la multiplie par le coefficient de la classe : 1 pour short, 10 pour medium et 15 pour long. Les jeux M4 disposent de leur propre table de longueurs de base.

« Long » ne désigne donc aucune durée universelle. Pour comparer des sorties, conservez la clé complète et la longueur calculée, avec la fréquence du jeu chargé. Cette lecture porte sur la révision du benchmark examinée en octobre ; elle ne reconstitue pas l’environnement exact de l’expérience décrite en septembre.

2. Quel historique entre réellement dans la recette publique ?

L’historique est transformé avant son envoi aux fonctions de prévision. Dans le script de TW3 Partners, révision d878dc4 du 21 septembre 2026, contexts_for parcourt les fenêtres d’entrée du jeu de test et extrait leurs valeurs cibles.

Pour chaque fenêtre, la fonction remplace explicitement les valeurs manquantes représentées par NaN par zéro, puis conserve au plus les 8 192 dernières valeurs. Elle examine ensuite ce contexte : s’il contient moins de 2 valeurs, ou si son écart-type est inférieur ou égal à 1e-12, elle lui ajoute les valeurs 0.0 et 1e-6. La longueur après préparation peut donc dépasser la longueur retenue lors de la troncature. Les objets comptés ici sont des valeurs temporelles.

Nous recommandons de consigner ces ajouts et le remplacement des valeurs manquantes dans toute comparaison qui reprend cette recette. Ce sont des opérations visibles dans le code ; leur pertinence pour un historique métier demande une évaluation propre.

Pour le backtest découpé dans les données d’entraînement, les auteurs de TW3Cast de TW3 Partners du 16 septembre 2026 indiquent que le MASE est calculé sur le contexte réel avant remplissage. La préparation des fenêtres d’entraînement est décrite séparément. Sur ce sujet, voir Normaliser des séries temporelles avec des valeurs aberrantes : la recette de TW3Cast et ses limites.

3. Pourquoi la longueur transmise peut-elle encore changer selon le modèle ?

Le contexte préparé peut encore être adapté dans les fonctions d’inférence. Le tableau décrit uniquement les opérations du script TW3 Partners à la révision d878dc4, du 21 septembre 2026.

Modèle et fonctionRéglage visibleCe qu’il faut distinguer
TimesFM, load_timesfmConfiguration avec max_context=2048Longueur préparée en amont et plafond demandé à la bibliothèque
Toto, quantiles_totoAdaptation à la taille de patch retenue par la recetteLongueur reçue et longueur après découpage ou complément
Chronos, quantiles_chronosConversion des contextes en tenseurs, puis appel à predict_quantilesValeurs transmises et traitement interne de la bibliothèque

Pour Toto, un patch correspond au bloc de valeurs auquel l’entrée est ajustée. Si le contexte est assez long, le script garde sa partie récente sur une longueur multiple de la taille du patch. S’il est plus court qu’un patch, il le complète à gauche en répétant sa première valeur. Il regroupe également les fenêtres de même longueur pour les calculer ensemble.

Ce parcours montre pourquoi une comparaison doit suivre l’entrée jusqu’à l’appel du modèle. Annoncer seulement la longueur préparée masque les adaptations ultérieures. Pour TimesFM, la valeur du tableau décrit une configuration demandée ; notre lecture du script s’arrête à cette interface avec la bibliothèque.

4. Comment le code produit-il un horizon supérieur à un bloc de sortie ?

Les recettes TiRex-2 et Toto prolongent leur contexte avec la médiane prévue avant de produire le bloc suivant. Les fonctions du script TW3 Partners du 21 septembre 2026 fixent par défaut max_h à 320 points pour TiRex-2 et à 128 pour Toto.

La boucle commence par demander le plus petit horizon entre la longueur restante et cette taille de bloc. Elle conserve les quantiles obtenus, retranche la longueur produite de l’horizon restant, puis poursuit si nécessaire. Le dernier bloc peut donc être plus court que les précédents.

Avant l’appel suivant, le code ajoute au contexte la tranche q[i, 4], décrite comme la médiane par les commentaires des fonctions. Les quantiles de chaque bloc restent conservés séparément. À la fin, les blocs sont concaténés sur l’axe temporel et les sorties sont triées sur l’axe des quantiles.

Notre lecture de ces boucles est la suivante : les blocs ultérieurs utilisent des valeurs déjà prédites. Le chemin visible prolonge chaque contexte par une seule suite de médianes ; il ne construit pas un ensemble de trajectoires probabilistes réinjectées séparément.

Ces tailles sont les paramètres par défaut de la recette examinée. Dans TW3Cast de TW3 Partners du 16 septembre 2026, les auteurs décrivent par ailleurs des cibles d’entraînement portant sur l’horizon complet ou sur le patch suivant, selon l’architecture. Il faut donc documenter le découpage effectivement utilisé pour produire la sortie.

5. Que change le traitement séparé des canaux ?

Le chemin public convertit les cibles multivariées en séries traitées séparément. Une prévision univariée traite une variable cible ; une prévision multivariée conjointe traite plusieurs canaux ensemble.

Dans le script TW3 Partners du 21 septembre 2026, contexts_for demande cette conversion lorsque la cible comporte plusieurs dimensions. La recette Toto est elle-même décrite comme univariée. Le code de Salesforce, révision 577a65c examinée le 9 octobre 2026, montre comment MultivariateToUnivariate crée une entrée par dimension et complète l’identifiant de série avec le suffixe _dim suivi de son indice.

Le périmètre de l’entrée change donc avant l’appel aux modèles. Il mérite une ligne explicite dans le descriptif d’une évaluation, au même titre que la longueur du contexte.

Dans leur réponse du 21 septembre 2026, les auteurs mentionnent aussi une prévision multivariée conjointe parmi les réglages de certaines lignes soumises. Cela explique pourquoi le nom du modèle et la longueur d’historique ne suffisent pas à identifier une recette de service.

6. Quels réglages faut-il rendre visibles dans une comparaison ?

Notre recommandation est de joindre à chaque résultat une description de l’entrée préparée et du calcul de sortie. La grille suivante est une proposition du cabinet issue de la lecture du script TW3 Partners du 21 septembre 2026.

Champ à documenterPoint de lecture dans le script
Contexte préparé, remplacements et ajoutscontexts_for
Plafond demandé et adaptation à la taille de patchload_timesfm, quantiles_toto
Horizon total demandéRetour de contexts_for, argument h
Découpage en blocs et valeurs réinjectéesquantiles_tirex2, quantiles_toto
Traitement séparé ou conjoint des canauxcontexts_for, entrée construite pour Toto
Niveaux de quantile et ordre des axesQL, fonctions quantiles_* et sortie de main

Le script annonce une sortie organisée par fenêtre, par quantile, puis par position dans l’horizon, avec 9 niveaux de 0,1 à 0,9. Conserver cette organisation avec le résultat permet de relier les valeurs évaluées aux fenêtres qui les ont produites. La prépublication TW3Cast de TW3 Partners du 16 septembre 2026 rattache les scores à la routine officielle d’évaluation de GIFT-Eval.

Une distinction complète ce descriptif. Selon le README de TW3 Partners du 21 septembre 2026, predict.py recalcule des prévisions depuis les modèles sauvegardés, tandis que replicate.py évalue les quantiles archivés derrière la soumission. Le premier décrit une recette de référence ; le second sert à vérifier les scores des sorties conservées.

7. Que reste-t-il à mesurer sur les séries de l’organisation ?

L’effet d’une longueur de contexte différente reste à mesurer sur les données concernées. TW3Cast de TW3 Partners du 16 septembre 2026 décrit des fenêtres d’entraînement à contexte variable et explicite une hypothèse de continuité du régime entre entraînement et test. La prépublication ne chiffre pas de gain isolé attribuable à l’allongement du contexte.

Nous recommandons de faire varier la longueur d’historique en gardant fixes le modèle, l’horizon et les autres réglages de la recette. Pour chaque essai, il convient de relever la longueur après préparation, puis celle présentée à l’interface du modèle. Cette précaution permet d’identifier les cas où une troncature ou un complément absorbe le changement demandé.

Le choix des périodes de comparaison doit également être explicite. Pour poursuivre, voir Choisir un modèle de prévision sans regarder les données de test : le backtest découpé dans la période d’entraînement. Retenez une longueur d’historique à partir des résultats de cette comparaison sur la source concernée.

FAQ

Un contexte plus long améliore-t-il toujours la prévision ?
Il est utile de comparer les longueurs à recette constante sur les données concernées. TW3Cast de TW3 Partners du 16 septembre 2026 décrit des contextes variables et une hypothèse de continuité du régime entre entraînement et test.

Que représente la borne de 8 192 valeurs dans la préparation du contexte ?
Dans le script de TW3 Partners du 21 septembre 2026, elle s’applique à la troncature dans contexts_for, avant les ajouts éventuels. Le plafond demandé pour TimesFM et l’adaptation aux patches de Toto interviennent ensuite.

Que signifie « long » dans une configuration GIFT-Eval ?
Dans le code GIFT-Eval de Salesforce, révision 577a65c examinée le 9 octobre 2026, cette classe détermine un multiplicateur appliqué à une longueur de base. Le calcul dépend aussi de la fréquence et de la table retenue pour le jeu de données.

Quelles valeurs alimentent les blocs de prévision suivants ?
Dans le script de TW3 Partners du 21 septembre 2026, les recettes TiRex-2 et Toto réinjectent leur médiane prévue. Les blocs ultérieurs sont donc calculés à partir d’un contexte prolongé par des prévisions.

Le script réalise-t-il toujours une prévision multivariée conjointe ?
Le script de TW3 Partners du 21 septembre 2026 sépare les cibles multivariées en séries univariées. Dans leur réponse publique du même jour, les auteurs documentent des variantes conjointes parmi les réglages de certaines prévisions soumises.

Le script public traite-t-il toutes les configurations de la table ?
Dans le script de TW3 Partners du 21 septembre 2026, main s’arrête lorsqu’une configuration relève du tournoi. La réponse publique des auteurs à cette même date précise que le code de sélection reste non publié et que les sorties archivées couvrent aussi ces configurations.

Pour aller plus loin

Sources