Backtesting IA des marchés de prédiction : tester les stratégies LLM sans fuite d'information future

Pourquoi le backtesting IA est un problème distinct

Une règle déterministe peut être examinée ligne par ligne. Un LLM peut modifier son raisonnement en fonction du prompt, de la version du modèle, du contexte, des résultats des outils et des paramètres d'échantillonnage. Il peut également connaître des faits survenus après la date simulée car ses données d'entraînement ou un outil de recherche attaché dépassent l'horloge historique. Un backtest de trading normal ne contrôle pas automatiquement ces risques.

Les marchés de prédiction rendent la fuite particulièrement sévère. La question du marché et la résolution finale sont publiques après le règlement, de sorte qu'un modèle peut sembler prévoir un événement tout en rappelant ou en déduisant sa réponse à partir d'informations ultérieures. Le test doit préserver à la fois l'intégrité du temps de marché et l'intégrité du temps du modèle.

Deux flux de travail de backtesting IA

Le flux de travail actuellement public de DepthFeed prend en charge la première voie : demander à un modèle de proposer une hypothèse claire, la traduire en une règle prédéfinie ou personnalisée, figer les paramètres et l'exécuter dans Backtest Lab. Cela sépare la génération d'idées de l'évaluation et rend le rejeu reproductible.

Un rejeu avec modèle dans la boucle nécessite des contrôles supplémentaires : un environnement d'information fermé, un état de portefeuille séquentiel, des enregistrements durables des appels au modèle et une bande ponctuelle pour chaque cycle. Ne décrivez pas une transcription de chat sur des marchés résolus comme cette forme plus forte de backtest.

Construire la frontière d'information historique

L'implémentation la plus sûre utilise une frontière à la date : horodatage source inférieur ou égal au moment de la décision. Chaque caractéristique, résumé et réponse d'outil doit hériter de cette frontière. Un seul champ de commodité non borné, tel que le statut du marché d'aujourd'hui ou une étiquette de résultat final, peut invalider l'exécution complète.

• Définissez un horodatage de décision et incluez uniquement les lignes de marché observées à ce moment ou avant.
• Délimitez explicitement toute fenêtre de recul ; n'utilisez jamais une ligne la plus proche qui pourrait provenir du futur.
• Excluez les résultats de règlement, les prix finaux, les titres ultérieurs et la recherche web actuelle.
• Enregistrez l'univers de marché exact montré au modèle, y compris les contrats qu'il a ignorés.
• Hachez ou versionnez la bande d'entrée afin que la même décision puisse être reconstruite ultérieurement.
• Signalez les données manquantes comme manquantes au lieu de les remplir à partir d'une observation ultérieure.

Empêcher la fuite de réponse et de prompt

Figez le prompt système, les instructions client, l'identifiant du modèle, le mode d'échantillonnage, le schéma de sortie structurée et les outils disponibles. Supprimez le langage qui révèle indirectement le résultat, y compris le statut final du marché, la formulation du règlement, les résumés d'articles rétrospectifs ou les noms de fichiers créés après la résolution.

Pour les questions d'événements historiques, supposez que la mémoire du modèle pré-entraîné peut contenir des faits ultérieurs même lorsque la navigation est désactivée. Utilisez des questions à l'abri de la coupure lorsque c'est possible, évaluez les contrôles de fuite séparément et comparez les performances sur des périodes plus récentes ou privées. Un score élevé sur des événements résolus bien connus n'est pas en soi une preuve de compétence en prévision.

Rendre le protocole de décision vérifiable

Demandez des actions structurées plutôt que des recommandations libres. Une décision utile inclut l'identité du marché, le côté, la probabilité estimée, la confiance, le prix d'entrée maximum, le notionnel demandé et une courte thèse. Les règles côté serveur doivent ensuite accepter, redimensionner ou rejeter la proposition en fonction des liquidités, de l'exposition, de la confiance, de l'avantage et des limites de prix.

Stockez les passes et les transactions rejetées, pas seulement les exécutions. Si le rapport final ne contient que les gagnants choisis par le modèle, il n'y a pas de dénominateur pour l'analyse de sélectivité, de couverture ou d'échec. L'enregistrement durable doit relier chaque action à sa frontière d'entrée exacte et à l'état de portefeuille résultant.

Rejouer le portefeuille séquentiellement

Les cycles de portefeuille doivent s'exécuter dans l'ordre chronologique car une décision modifie les liquidités et l'exposition ouverte disponibles pour la suivante. Parallélisez la découverte de marché à l'intérieur d'un horodatage si nécessaire, mais synthétisez une décision de portefeuille finale par rapport à une bande figée. Ne laissez pas des appels de modèle indépendants dépenser les mêmes liquidités.

Reportez les positions ouvertes, les liquidités réalisées et les limites de risque. Ensuite, rapportez le P&L par catégorie et par plateforme ainsi qu'en agrégé. Cela révèle si un portefeuille apparemment intelligent est un pari directionnel concentré répété sur des contrats corrélés.

Utilisez des exécutions réalisables, pas le prix indiqué par le modèle

Le modèle peut indiquer un prix maximum ; il ne doit pas être autorisé à inventer sa propre exécution. Ajoutez un délai d'exécution défini, localisez le premier carnet enregistré à ce moment simulé ou après, et parcourez les demandes ou offres disponibles uniquement jusqu'à la limite. Stockez VWAP, la fraction exécutée, le temps d'observation et le carnet utilisé.

Marquez le portefeuille final de manière prudente. Une évaluation au point médian suppose une liquidation sans traverser le spread ni consommer de taille. Une liquidation exécutable tenant compte de la profondeur répond mieux à ce que le portefeuille aurait pu réaliser ; les carnets périmés ou absents doivent rester une condition d'échec explicite.

Flux de travail opérationnel : d'une hypothèse LLM à un rejeu

Commencez par un prompt borné : demandez au modèle une hypothèse falsifiable Polymarket ou Kalshi, les entrées observables requises, une règle d'entrée précise, la taille de la position, le comportement de sortie ou de règlement et les conditions dans lesquelles elle doit réussir. Interdisez les revendications de profit et ne demandez pas d'exemples rétrospectifs.

Traduisez la réponse en un préréglage Backtest Lab ou une règle personnalisée sans modifier ses seuils après avoir vu les résultats. Sélectionnez la plateforme et la famille de marché prévues, utilisez un échantillon chronologique et comparez le point médian, le glissement fixe et la profondeur enregistrée. Inspectez chaque transaction et conservez un échantillon de validation ultérieur. Si elle survit, déployez la règle figée en paper trading et évaluez-la sur des résultats que le modèle n'aurait pas pu connaître lors de la création de la règle.

Métriques qui distinguent la prévision du trading

La qualité des prévisions et la performance de trading sont liées mais pas identiques. Un modèle calibré peut perdre en payant des prix qui reflètent déjà son information. Un modèle mal calibré peut gagner de l'argent brièvement par chance ou par une position concentrée. Rapportez les deux couches et évitez de réduire l'évaluation à un titre de classement.

Comparez les modèles sans déplacer les poteaux de but

• Donnez à chaque modèle la même bande de marché figée, le même ensemble d'outils, le même schéma de sortie et les mêmes limites de portefeuille.
• Utilisez les mêmes horodatages de décision, la même latence d'exécution, le même moteur d'exécution et la même règle de marquage final.
• Séparez les défaillances du fournisseur, les sorties invalides et les rejets par les règles de risque des pertes de marché.
• Enregistrez le coût des jetons et du modèle en même temps que la performance ; un gain marginal peut ne pas justifier un coût d'inférence beaucoup plus élevé.
• Répétez les exécutions stochastiques ou utilisez des paramètres déterministes lorsque c'est pris en charge, et rapportez la variance.
• Maintenez à jour les pages et les revendications des modèles nommés car les versions et la disponibilité des modèles changent.

Classifiez les échecs au lieu de les cacher

Ces résultats signifient des choses différentes. Traiter un délai d'attente du fournisseur comme une passe confiante gonfle la sélectivité ; supprimer un ordre non exécuté surestime la performance exécutable ; et réparer silencieusement une sortie de modèle mal formée donne à un modèle une aide humaine que les autres peuvent ne pas recevoir. L'évaluation doit définir chaque classe avant l'exécution et l'appliquer mécaniquement.

Publiez l'entonnoir complet : marchés éligibles, marchés montrés, actions proposées, passes, sorties invalides, rejets par les garde-fous, rejets d'exécution, exécutions partielles et positions terminées. Ce dénominateur permet de distinguer un modèle prudent d'un modèle peu fiable.

L'enregistrement minimum de reproductibilité

Pour chaque exécution, conservez le fournisseur du modèle et le slug exact du modèle, les modèles de prompt, les définitions d'outils, le schéma de sortie structurée, la configuration d'échantillonnage et les instructions client. Enregistrez le début et la fin historiques, l'intervalle de décision, la fenêtre de recul, les plateformes, les catégories, les liquidités de départ, les limites d'exposition, la latence d'exécution et la méthode de marquage final.

Pour chaque cycle de décision, conservez l'horodatage de décision, la version de la bande, le temps de la bande à la date, le nombre de marchés éligibles, le hachage d'entrée, le portefeuille avant et après, l'utilisation du modèle et l'état d'erreur. Pour chaque transaction proposée, stockez sa thèse et sa probabilité ainsi que la probabilité de marché observée, la confiance, le prix limite, la taille demandée, le code de rejet et le carnet historique utilisé pour toute exécution.

Les modèles des fournisseurs peuvent être mis à jour derrière un nom stable, de sorte qu'une réexécution exacte peut encore différer ultérieurement. Un enregistrement durable ne peut pas éliminer cette variance de plateforme, mais il peut la révéler. Lorsque les graines déterministes ou les versions épinglées ne sont pas disponibles, répétez le même test suffisamment de fois pour rapporter la dispersion d'une exécution à l'autre au lieu de présenter un échantillon favorable.

• Slug du modèle, fournisseur, prompt, outils, schéma et paramètres d'échantillonnage.
• Frontière historique, univers de marché, intervalle de décision et fenêtre de recul.
• Limites de portefeuille, latence d'exécution, moteur d'exécution et marquage final.
• Hachages d'entrée et de carnet liés à chaque décision et exécution.
• Utilisation des jetons, coût du modèle, sorties invalides et toutes les raisons de rejet.
• Variance des exécutions répétées lorsque le modèle ou le fournisseur est stochastique.

Testez en avant avant de faire une revendication de performance IA

Un test IA historique peut encore bénéficier de la mémoire du modèle, du réglage du prompt par le chercheur et de l'expérimentation répétée. L'étape suivante la plus propre est une période de paper trading en avant verrouillée. Figez le prompt ou la règle extraite, commencez après que la configuration est finale, évaluez chaque action à partir du carnet affiché en direct et publiez le dénominateur complet.

DepthFeed Paper Trading fournit la voie en avant disponible pour les règles déterministes et les signaux de bots externes. Il utilise des liquidités virtuelles et ne place pas d'ordres en direct sur les échanges. Cette distinction doit rester visible partout où un flux de travail IA est décrit.

Ce que DepthFeed offre aujourd'hui

Aujourd'hui, les chercheurs peuvent utiliser un modèle IA pour créer ou affiner une stratégie explicite, rejouer cette règle figée dans Backtest Lab par rapport aux carnets de marchés de prédiction enregistrés, comparer trois hypothèses d'exécution, inspecter le risque et les transactions individuelles, et déplacer les survivants compatibles vers le paper trading en direct. Les données historiques API et le serveur MCP prennent également en charge la recherche d'agents personnalisés en dehors du tableau de bord.

DepthFeed ne propose actuellement pas de backtest public autonome avec modèle dans la boucle API ni d'exécution de trading IA en direct. Le flux de travail plus étroit est intentionnel et testable : le modèle propose ; les preuves de marché enregistrées évaluent ; le paper trading fournit l'enregistrement en avant.