Algorithme de marché de prédiction : de l’estimation à l’ordre

Définir la cible de l’algorithme de marché de prédiction

L’algorithme commence par la plateforme, l’identifiant du contrat, le choix de l’issue et la condition exacte de règlement. Un modèle qui estime un événement général ne suffit pas si le contrat repose sur une source, un seuil ou une politique de révision particuliers. La probabilité doit porter sur l’instrument effectivement envisagé.

Formulez la cible de façon à pouvoir l’évaluer ultérieurement. Pour cet exemple hypothétique, supposez que la première publication désignée doit dépasser un seuil spécifié et que le versement simple est explicitement de 1 $ ou de 0 $. Les cas exceptionnels sont exclus par la définition de l’exemple ; leur absence n’est pas présumée dans les contrats réels.

Le guide antérieur consacré à l’algorithme de trading sur les marchés de prédiction fournit un cadre de conception plus large. Un algorithme utile ne peut pas compenser une cible indéfinie par un dimensionnement sophistiqué. Le sens du contrat est un préalable, car il détermine l’objet de la prévision et des calculs de versement.

Conserver la prévision et la date des éléments qui l’étayent

Supposons que le modèle fournisse une estimation centrale de la probabilité de Oui de 0,64. Consignez sa date d’émission, les éléments sources, la version du modèle et le périmètre d’évaluation. Ce nombre doit être une estimation de probabilité pour la cible définie, et non un score de classement ou une valeur de confiance interne rebaptisés probabilité.

L’estimation demeure incertaine. Pour cet exemple pédagogique, l’analyste examine également un scénario moins favorable, avec une probabilité de 0,58, afin de voir comment la proposition se comporte sous une hypothèse moins favorable. Ce scénario n’est pas une borne de confiance établie statistiquement, sauf si une méthode distincte justifie cette interprétation.

Conservez la prévision avant d’observer les résultats ultérieurs. Une simulation historique doit utiliser les informations disponibles au moment de la décision, y compris les données manquantes et les publications retardées. Le guide antérieur sur le trading algorithmique sur les marchés de prédiction explique pourquoi les corrections ultérieures ne doivent pas améliorer silencieusement les connaissances apparentes de l’algorithme à l’époque.

Définir une condition d’abstention de l’algorithme

Une condition d’abstention de l’algorithme précise les situations dans lesquelles aucune proposition ne doit être produite. Les cas pertinents comprennent une correspondance avec le contrat non résolue, des éléments de prévision expirés, des données de marché incomplètes ou un état de compte impossible à rapprocher. Chaque condition doit produire une raison lisible plutôt qu’un résultat numérique qui ressemble à une décision.

L’abstention n’est pas une prévision de probabilité nulle. Elle signifie qu’il manque une donnée requise au processus de décision ou que celui-ci sort de son périmètre autorisé. Conservez la dernière prévision valide comme élément historique si cela est utile, mais ne la transmettez pas comme actuelle simplement parce qu’aucune autre n’est disponible.

L’algorithme doit également distinguer l’admissibilité à la recherche de l’admissibilité au trading. Un contrat peut conserver un intérêt pour l’étude alors que les conditions actuelles du compte ou du marché empêchent toute action. Cette séparation aide les personnes chargées de l’examen à comprendre si le système a rejeté l’idée, l’a différée ou ne disposait pas des éléments nécessaires pour décider.

Lire le côté pertinent du carnet et les quantités disponibles

Une proposition d’achat de Oui nécessite les offres de vente actuelles et les quantités disponibles selon la représentation effective de la plateforme. Un cours médian affiché ou le prix de la dernière transaction ne suffisent pas. L’algorithme doit conserver l’horodatage du carnet et estimer le coût de la quantité envisagée, sans supposer que chaque unité peut être négociée au meilleur niveau.

Dans le carnet hypothétique, huit contrats sont proposés à 0,50 $ et dix autres à 0,52 $. Ces 18 contrats représentent la quantité disponible dans la limite de prix proposée à l’instant observé. Les autres offres éventuelles dépassent le prix autorisé dans le scénario et sont exclues.

Le guide sur le trading de contrats événementiels explique les mécanismes sous-jacents des coûts et des versements. L’algorithme utilise explicitement ces mécanismes. Une cotation est une donnée d’entrée de la proposition, tandis que les exécutions effectives établissent ensuite la quantité acquise et son coût. Les deux doivent rester distinctes dans l’historique.

Inclure les coûts selon une hypothèse explicite

À des fins pédagogiques, supposons des frais fictifs de 0,01 $ par contrat acquis et aucun autre coût dans ce scénario simplifié. Au prix d’achat maximal autorisé de 0,52 $, le coût maximal d’ouverture par contrat est donc de 0,53 $. Il s’agit d’une hypothèse de modélisation, et non du barème actuel d’une quelconque plateforme.

Les frais réels doivent être vérifiés en fonction du produit et des conditions de marché concernés. Les informations sur les frais de Kalshi indiquent que ceux-ci peuvent varier d’un marché à l’autre. Un algorithme doit utiliser les règles applicables en vigueur et conserver la version ou la source employée pour estimer ses coûts.

Si les coûts ne peuvent pas être estimés sur une base suffisamment étayée pour la stratégie, la proposition doit rester indisponible. Un faible avantage apparent peut disparaître sous l’effet d’un écart modeste de frais ou d’exécution. L’algorithme ne doit pas considérer les coûts inconnus comme nuls simplement parce que cela permet de poursuivre le calcul.

Calculer le scénario par contrat

Avec un versement simple de 1 $ ou de 0 $, une probabilité personnelle de 0,64 implique, selon cette estimation, un versement espéré de 0,64 $ par contrat. Par rapport au coût maximal modélisé de 0,53 $, l’écart espéré est de 0,11 $. Dans le scénario moins favorable, avec une probabilité de 0,58, il est de 0,05 $.

Il s’agit d’espérances sous certaines hypothèses, et non de gains garantis. Dans cet exemple, un contrat peut se régler sur Non et entraîner la perte de son coût d’ouverture. La prévision peut également être erronée et les conditions d’exécution peuvent changer. Le calcul sert à rendre explicite la relation entre probabilité, versement et coût.

Une politique de décision peut exiger une marge adaptée aux éléments qui l’étayent et à sa conception. Cet article n’en prescrit aucune. L’exigence essentielle est que cette politique soit écrite avant d’examiner les résultats et que l’incertitude sur la prévision ou les coûts ne soit pas masquée par un chiffre de valeur espérée d’apparence précise.

Appliquer la capacité de trésorerie avant de choisir la taille

Supposons que le processus hypothétique autorise au maximum 13,25 $ de nouveau coût d’ouverture pour cette proposition. En utilisant le coût prudent de 0,53 $ par contrat, ce budget permet au maximum 25 contrats, car 25 multiplié par 0,53 $ égale 13,25 $. La quantité doit respecter les incréments réellement pris en charge par la plateforme.

Il s’agit d’un calcul de capacité, et non d’un budget ou d’une règle de dimensionnement recommandés. L’algorithme doit utiliser le montant effectivement autorisé et l’état réel du compte. Les fonds déjà engagés ailleurs ne peuvent pas être comptés deux fois, et un statut d’ordre inconnu peut rendre la capacité disponible apparente peu fiable.

Conservez la source du budget et sa date. Si le compte change avant l’autorisation, recalculez ou invalidez la proposition selon la politique définie. Le maintien d’une prévision inchangée ne signifie pas que le compte dispose encore de la même capacité d’action. L’analyse du marché et l’autorisation des ressources relèvent de niveaux distincts.

Prendre en compte l’exposition existante et les engagements ouverts

Supposons maintenant que le processus impose un plafond hypothétique de 40 contrats Oui exposés au regroupement d’événements concerné. Il en détient déjà 20 et en a deux autres dans un autre engagement ouvert. La capacité restante est de 18 contrats : 40 moins 20 moins deux. Cette contrainte est plus stricte que la capacité de trésorerie de 25.

Le regroupement d’événements doit avoir une signification définie. Plusieurs contrats peuvent partager un même facteur de risque même si leurs noms diffèrent. Un système réel peut utiliser une mesure du risque plus adaptée que le nombre de contrats, notamment lorsque les versements ou les structures diffèrent. La simple limite en nombre retenue ici sert uniquement à rendre les calculs visibles.

Le guide sur les algorithmes de marchés de prédiction compare les méthodes et leurs hypothèses. Cet exemple montre pourquoi une prévision favorable prise isolément ne peut pas déterminer à elle seule la taille. L’exposition et les engagements existants peuvent encadrer la proposition indépendamment de la confiance du modèle.

Retenir la plus petite capacité étayée

Les limites hypothétiques sont désormais de 25 contrats selon la trésorerie, de 18 selon le plafond d’exposition à l’événement et de 18 selon le carnet observé dans la limite de prix. La proposition encadrée porte donc sur 18 contrats au maximum. Une autre politique pourrait imposer une limite encore plus faible, et l’absence d’un préalable empêcherait toute proposition.

Le coût maximal d’ouverture réservé selon la borne prudente est de 18 multiplié par 0,53 $, soit 9,54 $. Le carnet observé suggère un coût inférieur avant frais : huit contrats à 0,50 $ coûtent 4 $, et dix à 0,52 $ coûtent 5,20 $. Le total est de 9,20 $ avant les frais fictifs de 0,18 $, soit 9,38 $ tous frais compris.

Distinguez la borne maximale de l’estimation observée. La première étaye l’autorisation dans la limite indiquée, tandis que la seconde décrit le scénario du carnet actuel. Aucune des deux n’est une exécution réelle. Cette distinction évite qu’un écart ultérieur d’exécution soit pris pour une incohérence dans une identité comptable.

Vérifier le scénario espéré global sans en exagérer la portée

Avec l’estimation centrale de 0,64, 18 contrats simples à 1 $ ont un versement espéré modélisé de 11,52 $. En soustrayant l’estimation observée de 9,38 $ tous frais compris, on obtient un écart espéré de 2,14 $. Dans le scénario moins favorable, avec une probabilité de 0,58, le versement espéré est de 10,44 $ et l’écart de 1,06 $.

Dans cet exemple simple, le versement effectivement possible reste de 18 $ ou de zéro si les 18 contrats sont conservés jusqu’à la résolution. L’espérance est une moyenne impliquée par un modèle de probabilité, et non une troisième issue de règlement. Cette distinction est essentielle pour présenter les calculs à des lecteurs qui pourraient confondre valeur espérée et somme promise.

L’analyse de sensibilité doit inclure d’autres hypothèses que la probabilité. Les coûts peuvent changer, les règles peuvent être mal comprises et seule une partie de la proposition peut être exécutée. L’algorithme doit conserver la trace de ces possibilités et éviter de présenter l’espérance globale comme une mesure complète de tous les risques pertinents.

Autoriser une version précise de la proposition

L’autorisation doit porter sur un contrat, un sens de transaction, une quantité, une limite de prix et une version des éléments justificatifs définis. Si ces données changent sensiblement, le système doit disposer d’une politique pour actualiser ou rejeter la proposition. Une approbation antérieure ne doit pas devenir une permission illimitée d’agir quelles que soient les conditions ultérieures du marché.

Le guide sur les logiciels d’automatisation des marchés de prédiction développe les permissions et la gestion des exceptions. Le composant qui produit les prévisions peut rester distinct de celui qui vérifie les autorisations du compte. Cette séparation facilite l’identification de la décision qui a permis l’action externe.

Consignez une condition d’expiration. Une proposition peut devenir périmée à cause du temps écoulé, d’un carnet modifié, d’une transition d’état du contrat ou de nouveaux éléments concernant le compte. L’expiration ne doit pas effacer l’historique de recherche ; elle signifie que l’action précise n’est plus étayée dans les conditions qui l’avaient initialement autorisée.

Distinguer la soumission de l’achèvement

Soumettre la proposition autorisée crée une tentative, pas nécessairement une position constituée. Conservez la référence de la tentative et la réponse effective de la plateforme. Le système doit distinguer les états accepté, ouvert, partiellement exécuté, annulé, rejeté et inconnu selon l’implémentation actuelle, au lieu de les réduire à un unique indicateur de réussite.

Si la réponse est inconnue, rapprochez les informations sur la tentative existante avant d’en créer une autre. Un nouvel ordre peut doubler l’exposition si l’ordre initial a déjà été exécuté ou reste actif. Une prévision répétée ou une notification répétée ne constitue pas une nouvelle autorisation d’ignorer cette incertitude.

Le guide antérieur sur l’API de bot pour les marchés de prédiction explique pourquoi ces distinctions comptent. Un algorithme doit produire une chaîne vérifiable, de la prévision à la proposition autorisée, puis à la tentative. Il ne doit pas considérer chaque nouvelle tentative comme une nouvelle décision économique simplement parce que la fonction logicielle peut être appelée à nouveau.

Recalculer après une exécution partielle

Supposons que l’ordre hypothétique soit exécuté pour huit contrats à 0,50 $ et quatre à 0,52 $. Le coût avant frais est de 4 $ plus 2,08 $, soit 6,08 $. Avec les frais fictifs de 0,01 $ sur chacun des 12 contrats acquis, le coût total d’ouverture atteint 6,20 $. Six des 18 contrats proposés restent non exécutés.

Le compte détient désormais 32 contrats dans le regroupement d’événements simplifié : les 20 initiaux plus les 12 nouveaux. Il compte également deux contrats dans l’engagement distinct antérieur et six restants issus de cette proposition. Ensemble, ils atteignent toujours le plafond de 40 contrats si toutes les quantités ouvertes sont exécutées.

L’algorithme doit décider du sort des six contrats restants selon sa politique actuelle. Il ne peut ni raisonner comme si les 18 avaient été acquis, ni ignorer l’engagement restant lorsqu’il envisage une nouvelle proposition. Les exécutions effectives et les demandes actives doivent toutes deux être prises en compte dans le calcul de capacité.

Rapprocher les coûts et l’état de la position

Une fois que l’ordre atteint un état connu, comparez l’historique des exécutions, les frais, la quantité en position et la capacité disponible. Pour examiner un compte réel, utilisez les montants effectivement facturés plutôt que l’aperçu hypothétique. Conservez toute divergence et sa source au lieu d’ajuster silencieusement les chiffres jusqu’à ce que les totaux paraissent plausibles.

Si la quantité restante est annulée, attendez la confirmation de l’état concerné avant de libérer son engagement dans le registre interne. Selon le fonctionnement réel de la plateforme, une demande d’annulation peut entrer en concurrence avec des exécutions. La quantité finale doit provenir des éléments rapprochés.

L’historique de décision de l’algorithme doit conserver à la fois le scénario de prévision et le déroulement effectif des opérations sur le compte. Cela permet une évaluation ultérieure. Une prévision utile peut subir une mauvaise exécution, et une prévision médiocre peut produire un résultat isolé favorable. L’historique doit permettre de distinguer ces cas plutôt que de les réduire à un seul chiffre de profit.

Tester le calcul qui mène de la prévision à l’ordre

Le calcul qui mène de la prévision à l’ordre doit être vérifié avec des cas qui sollicitent de véritables limites. Utilisez une prévision expirée, un contrat ambigu, un carnet périmé, une capacité de trésorerie insuffisante et une tentative antérieure d’état inconnu. Chacun doit produire l’abstention ou la réduction de taille définie avant d’envisager toute soumission.

Testez les calculs avec les valeurs hypothétiques de ce guide. Confirmez le plafond de 18 contrats, la borne prudente de 9,54 $, l’estimation de 9,38 $ fondée sur le carnet et le coût de 6,20 $ de l’exécution partielle de 12 contrats. Ces vérifications valident des relations significatives au lieu de reproduire des détails arbitraires d’implémentation.

Testez aussi un cas où le résultat correct est l’absence d’action malgré une prévision élevée. Par exemple, une capacité d’exposition restante nulle doit bloquer la proposition. Cela démontre que l’algorithme respecte des contraintes indépendantes au lieu de laisser la confiance l’emporter sur la politique du compte.

Examiner quelles propositions sont effectivement exécutées

Une prévision évaluée sur l’ensemble des transactions proposées peut se comporter différemment sur le sous-ensemble effectivement exécuté. Un ordre d’achat en attente peut avoir davantage de chances d’être exécuté après qu’une information a rendu le contrat moins attrayant aux yeux des autres participants. L’algorithme doit donc examiner les conditions entourant les exécutions au lieu de supposer que les ordres exécutés constituent un échantillon aléatoire de ses propositions.

Dans une étude historique, le fait qu’un prix atteigne la limite ne suffit pas à établir que la quantité entière de l’algorithme aurait été exécutée. La quantité disponible, le moment précis et les règles effectives d’appariement de la plateforme comptent. Utilisez un modèle d’exécution étayé et identifiez ses limites. Une hypothèse d’exécution excessivement généreuse peut faire paraître un calcul rigoureux de la prévision à l’ordre plus efficace qu’un processus réel ne pourrait l’être.

Conservez les propositions non exécutées et annulées ainsi que celles qui ont été exécutées. Comparez l’état des éléments disponibles au moment de l’autorisation à celui observé à proximité des exécutions effectives lorsque les données le permettent. Si la prévision expire alors qu’un ordre reste ouvert, la politique doit préciser si cet engagement doit être réexaminé ou retiré. L’estimation favorable initiale ne doit pas rester une justification permanente de toute exécution ultérieure.

Cet examen relie prévision et exécution sans les confondre. Le modèle peut rester bien calibré sur sa cible prévue tandis que la politique d’ordres sélectionne un sous-ensemble de moments défavorables. Inversement, l’exécution peut être précise alors que la prévision est médiocre. Un historique utile permet à la personne chargée de l’examen d’identifier l’hypothèse à réviser au lieu d’attribuer chaque résultat au seul modèle de probabilité.

Un algorithme de marché de prédiction doit rendre toutes ses hypothèses explicites

L’algorithme achevé peut expliquer pourquoi il a envisagé le contrat, quelle estimation de probabilité il a utilisée, comment les coûts ont été modélisés et quelle limite a déterminé la taille finale. Il peut aussi expliquer pourquoi une proposition a expiré ou pourquoi une tentative reste non résolue. Ces explications font partie de la conception ; elles ne sont pas des commentaires facultatifs ajoutés après coup.

L’exemple hypothétique a abouti à un maximum de 18 contrats parce que la trésorerie, l’exposition et la profondeur ont été évaluées séparément. Ses calculs de valeur espérée dépendaient d’une prévision incertaine et de coûts explicites. Sa position réelle dépendait des exécutions. Garder ces distinctions visibles évite de prendre une formule élégante pour un résultat de trading garanti.

Construisez le processus comme une chaîne de décisions étayées assortie de conditions d’arrêt claires. Conservez les éléments justificatifs et rapprochez les informations sur ce qui se produit effectivement. Vous obtenez ainsi un algorithme dont le comportement peut être testé, examiné et révisé sans cacher ses hypothèses dans un score opaque unique ni traiter une soumission incertaine comme une permission de recommencer.