Algorytm rynku predykcyjnego: od szacunku do zlecenia

Zdefiniuj cel algorytmu rynku predykcyjnego

Algorytm zaczyna od platformy, identyfikatora kontraktu, wybranego wyniku i dokładnego warunku rozliczenia. Model szacujący szeroko rozumiane zdarzenie nie wystarcza, jeśli kontrakt wykorzystuje określone źródło, próg lub zasady rewizji danych. Prawdopodobieństwo musi odnosić się do rzeczywiście rozważanego instrumentu.

Zapisz cel w postaci pozwalającej później go ocenić. W hipotetycznym przykładzie przyjmij, że wskazana pierwsza publikacja musi przekroczyć określony próg, a prosta wypłata wynosi jawnie $1 albo $0. Przypadki wyjątkowe wyklucza definicja przykładu; nie zakłada się, że nie występują w rzeczywistych kontraktach.

Wcześniejszy poradnik o algorytmie handlu na rynku predykcyjnym przedstawia szersze ramy projektowania. Użyteczny algorytm nie naprawi niezdefiniowanego celu za pomocą zaawansowanego ustalania wielkości pozycji. Znaczenie kontraktu jest warunkiem wstępnym, ponieważ określa, czego dotyczą prognoza i obliczenia wypłaty.

Zachowaj prognozę i czas jej danych źródłowych

Załóżmy, że model podaje centralny szacunek prawdopodobieństwa Tak równy 0.64. Zapisz czas jego wydania, dane źródłowe, wersję modelu i zakres oceny. Liczba powinna być szacunkiem prawdopodobieństwa zdefiniowanego celu, a nie wynikiem rankingowym lub wewnętrzną miarą pewności przemianowaną na prawdopodobieństwo.

Szacunek pozostaje niepewny. W tym przykładzie dydaktycznym analityk bada również niższy scenariusz 0.58, aby zobaczyć zachowanie propozycji przy mniej korzystnym założeniu. Scenariusz ten nie jest statystycznie ustaloną granicą przedziału ufności, chyba że odrębna metoda uzasadnia taką interpretację.

Zachowaj prognozę przed poznaniem późniejszych wyników. Odtworzenie historyczne musi wykorzystywać informacje dostępne w chwili decyzji, w tym brakujące dane wejściowe i opóźnione publikacje. Wcześniejszy poradnik o handlu algorytmicznym na rynku predykcyjnym wyjaśnia, dlaczego późniejsze korekty nie powinny po cichu poprawiać pozornej wiedzy wcześniejszego algorytmu.

Zdefiniuj warunek powstrzymania się od działania

Warunek powstrzymania się algorytmu od działania określa, kiedy nie należy tworzyć propozycji. Obejmuje to nierozstrzygnięte przyporządkowanie kontraktu, wygasłe dane prognozy, niepełne dane rynku lub stan konta, którego nie można uzgodnić. Każdy warunek powinien dawać czytelne uzasadnienie zamiast wyniku liczbowego wyglądającego jak decyzja.

Powstrzymanie się od działania nie oznacza prognozy zerowego prawdopodobieństwa. Oznacza brak wymaganego wejścia w procesie decyzyjnym albo wyjście poza upoważniony zakres. Zachowaj ostatnią poprawną prognozę jako historyczny materiał dowodowy, jeśli jest przydatna, lecz nie przekazuj jej dalej jako aktualnej tylko dlatego, że nie ma następnej.

Algorytm powinien też rozróżniać dopuszczalność badania i dopuszczalność handlu. Kontrakt może nadal być interesujący badawczo, choć obecne warunki konta lub rynku uniemożliwiają działanie. To rozdzielenie pomaga oceniającym zrozumieć, czy system odrzucił pomysł, odroczył go, czy nie miał danych potrzebnych do decyzji.

Odczytaj właściwą stronę rynku i dostępną ilość

Propozycja kupna Tak wymaga aktualnych ofert sprzedaży i dostępnych ilości zgodnie z rzeczywistą reprezentacją platformy. Wyświetlana cena środkowa lub ostatnia transakcja nie wystarczają. Algorytm powinien zachować znacznik czasu arkusza i oszacować koszt zamierzonej wielkości, zamiast zakładać, że każdą jednostkę można kupić po najlepszej cenie.

W hipotetycznym arkuszu osiem kontraktów oferuje się po $0.50, a kolejne dziesięć po $0.52. Te 18 kontraktów stanowi ilość dostępną w proponowanym limicie ceny w obserwowanej chwili. Inne oferty, jeśli występują, leżą poza dozwoloną ceną scenariusza i są wykluczone.

Poradnik o handlu kontraktami zdarzeniowymi wyjaśnia podstawową mechanikę kosztów i wypłat. Algorytm jawnie ją wykorzystuje. Kwotowanie jest wejściem do propozycji, natomiast dopiero rzeczywiste realizacje ustalają nabytą ilość i koszt. W zapisie należy je rozdzielać.

Uwzględnij koszty przy nazwanym założeniu

Do celów dydaktycznych przyjmijmy wymyśloną opłatę $0.01 za nabyty kontrakt i brak innych obciążeń w uproszczonym scenariuszu. Przy najwyższej dozwolonej cenie kupna $0.52 maksymalny koszt otwarcia na kontrakt wynosi zatem $0.53. Jest to założenie modelu, a nie aktualna tabela opłat jakiejkolwiek platformy.

Rzeczywiste opłaty trzeba sprawdzić dla odpowiedniego produktu i warunków rynku. Informacje Kalshi o opłatach wskazują, że mogą się one różnić między rynkami. Algorytm powinien stosować aktualne właściwe reguły i zachowywać wersję lub źródło wykorzystane do oszacowania kosztów.

Jeśli kosztów nie można oszacować na podstawach wystarczających dla strategii, propozycja powinna pozostać niedostępna. Niewielka pozorna przewaga może zniknąć wskutek skromnej różnicy opłaty lub wykonania. Algorytm nie powinien uznawać nieznanych kosztów za zerowe tylko dlatego, że pozwala to kontynuować obliczenia.

Oblicz scenariusz na jeden kontrakt

Przy prostej wypłacie $1 lub $0 osobisty szacunek prawdopodobieństwa 0.64 oznacza według tego szacunku oczekiwaną wypłatę $0.64 na kontrakt. W porównaniu z maksymalnym modelowanym kosztem $0.53 oczekiwana różnica wynosi $0.11. W niższym scenariuszu 0.58 wynosi ona $0.05.

Są to wartości oczekiwane przy założeniach, a nie gwarantowane zyski. Kontrakt może rozliczyć się jako Nie, tracąc w przykładzie koszt otwarcia. Prognoza również może być błędna, a warunki wykonania mogą się zmienić. Obliczenie ma ujawnić związek prawdopodobieństwa, wypłaty i kosztu.

Polityka decyzyjna może wymagać marginesu odpowiedniego do własnych danych i konstrukcji. Ten artykuł go nie narzuca. Ważne, aby politykę zapisano przed poznaniem wyników i aby niepewność prognozy lub kosztów nie kryła się za pozornie precyzyjną wartością oczekiwaną.

Zastosuj ograniczenie gotówki przed wyborem wielkości

Załóżmy, że hipotetyczny proces dopuszcza najwyżej $13.25 nowego kosztu otwarcia dla tej propozycji. Przy zachowawczym koszcie $0.53 na kontrakt budżet wystarcza najwyżej na 25 kontraktów, ponieważ 25 pomnożone przez $0.53 równa się $13.25. Ilość musi respektować przyrosty faktycznie obsługiwane przez platformę.

To obliczenie dostępnej zdolności, a nie zalecany budżet ani reguła wielkości pozycji. Algorytm powinien korzystać z rzeczywistej upoważnionej kwoty i stanu konta. Środków już zaangażowanych gdzie indziej nie można liczyć dwukrotnie, a nieznany status zlecenia może podważać wiarygodność pozornie dostępnych zasobów.

Zachowaj źródło budżetu i jego czas. Jeśli konto zmieni się przed zatwierdzeniem, przelicz lub unieważnij propozycję zgodnie ze zdefiniowaną polityką. Niezmieniona prognoza nie oznacza, że konto nadal ma tę samą zdolność działania. Analiza rynku i upoważnienie do wykorzystania zasobów to odrębne warstwy.

Uwzględnij istniejącą ekspozycję i otwarte zobowiązania

Załóżmy teraz hipotetyczny limit 40 kontraktów Tak narażonych na odpowiednią grupę zdarzeń. Proces posiada już 20 i ma dwa kolejne w innym otwartym zobowiązaniu. Pozostaje miejsce na 18 kontraktów: 40 minus 20 minus dwa. To ograniczenie jest ciaśniejsze niż wynikające z gotówki 25.

Grupowanie zdarzeń musi mieć określone znaczenie. Kilka kontraktów może współdzielić czynnik ryzyka, mimo różnych nazw. Rzeczywisty system może stosować miarę ryzyka właściwszą niż liczba kontraktów, zwłaszcza przy różnych wypłatach lub konstrukcjach. Prosty limit liczbowy wybrano tu wyłącznie dla przejrzystości rachunku.

Poradnik o algorytmach rynku predykcyjnego porównuje metody i ich założenia. Ten przykład pokazuje, dlaczego korzystna prognoza rozpatrywana osobno nie może sama określać wielkości. Istniejąca ekspozycja i zobowiązania mogą ograniczać propozycję niezależnie od pewności modelu.

Wykorzystaj najmniejszą uzasadnioną zdolność

Hipotetyczne limity wynoszą teraz 25 kontraktów z gotówki, 18 z limitu zdarzenia i 18 z obserwowanego arkusza w granicy ceny. Ograniczona propozycja wynosi zatem najwyżej 18 kontraktów. Inna polityka mogłaby narzucić jeszcze mniejszy limit, a brak warunku wstępnego oznaczałby brak propozycji.

Maksymalny zarezerwowany koszt otwarcia przy zachowawczej granicy wynosi 18 razy $0.53, czyli $9.54. Obserwowany arkusz sugeruje niższy koszt przed opłatą: osiem po $0.50 kosztuje $4, a dziesięć po $0.52 kosztuje $5.20. Razem to $9.20 przed wymyśloną opłatą $0.18, czyli $9.38 ze wszystkimi kosztami.

Oddziel maksymalną granicę od obserwowanego szacunku. Pierwsza uzasadnia zatwierdzenie w określonym limicie, a drugi opisuje obecny scenariusz arkusza. Żadne nie jest rzeczywistą realizacją. To rozróżnienie zapobiega uznaniu późniejszej różnicy wykonania za naruszoną tożsamość księgową.

Sprawdź łączną wartość oczekiwaną bez nadmiernych twierdzeń

Przy centralnym szacunku 0.64 modelowana oczekiwana wypłata 18 prostych kontraktów po $1 wynosi $11.52. Po odjęciu obserwowanego szacunku wszystkich kosztów $9.38 oczekiwana różnica wynosi $2.14. W niższym scenariuszu 0.58 oczekiwana wypłata to $10.44, a różnica $1.06.

Możliwa faktyczna wypłata w prostym przykładzie nadal wynosi albo $18, albo zero, jeśli wszystkie 18 zostanie utrzymane do rozstrzygnięcia. Wartość oczekiwana jest średnią wynikającą z modelu prawdopodobieństwa, a nie trzecim wynikiem rozliczenia. Rozróżnienie to jest niezbędne przy przedstawianiu obliczeń czytelnikom, którzy mogliby pomylić wartość oczekiwaną z obiecaną gotówką.

Analiza wrażliwości powinna obejmować również inne założenia niż prawdopodobieństwo. Koszty mogą się zmienić, reguły mogą zostać błędnie zrozumiane, a propozycja może zrealizować się tylko częściowo. Algorytm powinien zachowywać te możliwości i unikać przedstawiania łącznej wartości oczekiwanej jako pełnej miary wszystkich istotnych rodzajów ryzyka.

Zatwierdź konkretną wersję propozycji

Upoważnienie powinno dotyczyć określonego kontraktu, strony, ilości, granicy ceny i wersji danych. Jeśli te wejścia istotnie się zmienią, system potrzebuje polityki odświeżenia lub odrzucenia propozycji. Wcześniejsza zgoda nie powinna stawać się nieograniczonym pozwoleniem na działanie w dowolnych późniejszych warunkach rynkowych.

Poradnik o oprogramowaniu automatyzacji rynku predykcyjnego rozwija temat uprawnień i obsługi wyjątków. Komponent tworzący prognozy może pozostawać oddzielony od komponentu sprawdzającego upoważnienie konta. To rozdzielenie ułatwia ustalenie, która decyzja dopuściła działanie zewnętrzne.

Zapisz warunek wygaśnięcia. Propozycja może się zdezaktualizować z powodu upływu czasu, zmiany arkusza, przejścia stanu kontraktu lub nowych danych konta. Wygaśnięcie nie powinno usuwać zapisu badawczego; oznacza, że konkretne działanie nie jest już uzasadnione warunkami, w których pierwotnie je zatwierdzono.

Odróżniaj wysłanie od zakończenia

Wysłanie zatwierdzonej propozycji tworzy próbę, niekoniecznie ukończoną pozycję. Zachowaj identyfikator próby i rzeczywistą odpowiedź platformy. System powinien rozróżniać stany przyjęte, otwarte, częściowo zrealizowane, anulowane, odrzucone i nieznane zgodnie z aktualną implementacją, zamiast wciskać je w pojedynczy znacznik sukcesu.

Jeśli odpowiedź jest nieznana, uzgodnij istniejącą próbę przed utworzeniem kolejnej. Nowe zlecenie może zdublować ekspozycję, jeśli pierwotne już zrealizowano lub nadal jest aktywne. Powtórzona prognoza lub powtórzone powiadomienie nie stanowią nowego upoważnienia do pominięcia tej niepewności.

Wcześniejszy poradnik o API bota rynku predykcyjnego wyjaśnia znaczenie tych granic. Algorytm powinien tworzyć możliwy do zbadania łańcuch od prognozy przez zatwierdzoną propozycję do próby. Nie powinien traktować każdego ponowienia jako nowej decyzji ekonomicznej tylko dlatego, że funkcję programu można wywołać ponownie.

Przelicz po częściowej realizacji

Załóżmy, że hipotetyczne zlecenie realizuje osiem kontraktów po $0.50 i cztery po $0.52. Koszt przed opłatą wynosi $4 plus $2.08, czyli $6.08. Przy wymyślonej opłacie $0.01 za każdy z 12 nabytych kontraktów łączny koszt otwarcia wynosi $6.20. Sześć z proponowanych 18 pozostaje niezrealizowanych.

Konto posiada teraz 32 kontrakty w uproszczonej grupie zdarzeń: pierwotne 20 plus nowe 12. Ma także dwa kontrakty we wcześniejszym odrębnym zobowiązaniu i sześć pozostałych z tej propozycji. Łącznie nadal wyczerpują limit 40 kontraktów, jeśli wszystkie otwarte ilości zostaną zrealizowane.

Algorytm musi zdecydować, co dzieje się z pozostałymi sześcioma zgodnie z aktualną polityką. Nie może rozumować tak, jakby nabyto wszystkie 18, ani pomijać pozostałego zobowiązania przy rozważaniu nowej propozycji. Zarówno rzeczywiste realizacje, jak i aktywne żądania muszą być uwzględnione w obliczeniu dostępnej zdolności.

Uzgodnij koszty i stan pozycji

Po osiągnięciu przez zlecenie znanego stanu porównaj zapis realizacji, opłaty, ilość pozycji i dostępną zdolność. Przy analizie rzeczywistego konta używaj faktycznie pobranych kwot zamiast hipotetycznego podglądu. Zachowaj każdą rozbieżność i jej źródło, zamiast po cichu korygować liczby, aż sumy zaczną wyglądać wiarygodnie.

Jeśli pozostała ilość zostanie anulowana, poczekaj na odpowiedni potwierdzony stan przed zwolnieniem jej zobowiązania w wewnętrznej ewidencji. Żądanie anulowania może zbiec się w czasie z realizacjami zgodnie z rzeczywistym działaniem platformy. Ostateczna ilość musi wynikać z uzgodnionych danych.

Zapis decyzji algorytmu powinien zachowywać zarówno scenariusz prognozy, jak i rzeczywisty przebieg konta. Umożliwia to późniejszą ocenę. Użyteczna prognoza może napotkać złe wykonanie, a słaba prognoza może dać korzystny pojedynczy wynik. Zapis powinien pozwalać odróżnić te przypadki, zamiast redukować je do jednej liczby zysku.

Przetestuj obliczenie od prognozy do zlecenia

Obliczenie od prognozy do zlecenia należy sprawdzać przypadkami badającymi rzeczywiste granice. Wykorzystaj wygasłą prognozę, niejednoznaczny kontrakt, nieaktualny arkusz, niewystarczającą gotówkę i nieznaną wcześniejszą próbę. Każdy powinien powodować zdefiniowane powstrzymanie się od działania lub zmniejszenie wielkości przed rozważeniem wysłania.

Przetestuj rachunek na hipotetycznych wartościach z tego poradnika. Potwierdź limit 18 kontraktów, zachowawczą granicę $9.54, szacunek z arkusza $9.38 i koszt $6.20 częściowej realizacji 12 kontraktów. Te sprawdzenia weryfikują istotne związki, zamiast odzwierciedlać arbitralne szczegóły implementacji.

Przetestuj również przypadek, w którym poprawnym wynikiem jest brak działania mimo wysokiej prognozy. Na przykład zerowa pozostała zdolność ekspozycji powinna blokować propozycję. Pokazuje to, że algorytm respektuje niezależne ograniczenia, zamiast pozwalać pewności przeważyć nad polityką konta.

Zbadaj, które propozycje rzeczywiście są realizowane

Prognoza oceniana na wszystkich proponowanych transakcjach może zachowywać się inaczej w podzbiorze rzeczywiście realizowanym. Oczekujące zlecenie kupna może mieć większą szansę wykonania po pojawieniu się informacji czyniącej kontrakt mniej atrakcyjnym dla innych uczestników. Algorytm powinien zatem badać warunki otaczające realizacje, zamiast zakładać, że ukończone zlecenia są losową próbą jego propozycji.

W badaniu historycznym samo dotknięcie limitu przez cenę nie dowodzi, że cała ilość algorytmu zostałaby zrealizowana. Znaczenie mają dostępna wielkość, czas i rzeczywiste reguły kojarzenia platformy. Używaj uzasadnionego modelu wykonania i określaj jego ograniczenia. Nierealistycznie hojny model realizacji może sprawić, że staranny rachunek od prognozy do zlecenia wygląda skuteczniej niż rzeczywisty proces.

Zachowuj propozycje niezrealizowane i anulowane obok ukończonych. Porównuj stan danych przy zatwierdzeniu ze stanem w pobliżu rzeczywistych realizacji, jeśli dane na to pozwalają. Jeśli prognoza wygasa przy nadal otwartym zleceniu, polityka musi określać, czy zobowiązanie należy ponownie ocenić lub wycofać. Pierwotny korzystny szacunek nie powinien pozostawać trwałym uzasadnieniem każdej późniejszej realizacji.

Ta analiza łączy prognozowanie z wykonaniem, nie zacierając ich odrębności. Model może pozostawać dobrze skalibrowany dla zamierzonego celu, podczas gdy polityka zleceń wybiera niekorzystny podzbiór chwil. Odwrotnie, wykonanie może być dokładne przy słabej prognozie. Użyteczny zapis pozwala oceniającemu ustalić, które założenie wymaga rewizji, zamiast przypisywać każdy wynik wyłącznie modelowi prawdopodobieństwa.

Algorytm rynku predykcyjnego powinien ujawniać każde założenie

Gotowy algorytm potrafi wyjaśnić, dlaczego rozważał kontrakt, którego szacunku prawdopodobieństwa użył, jak modelował koszty i który limit wyznaczył ostateczną wielkość. Potrafi też wyjaśnić, dlaczego propozycja wygasła lub próba pozostaje nierozstrzygnięta. Te wyjaśnienia są częścią projektu, a nie opcjonalnym komentarzem dodanym później.

Hipotetyczny przykład dał najwyżej 18 kontraktów, ponieważ gotówkę, ekspozycję i głębokość oceniano oddzielnie. Obliczenia wartości oczekiwanej zależały od niepewnej prognozy i jawnych kosztów. Faktyczna pozycja zależała od realizacji. Widoczność tych różnic zapobiega pomyleniu zgrabnego wzoru z gwarantowanym wynikiem handlowym.

Buduj proces jako łańcuch uzasadnionych decyzji z jasnymi warunkami zatrzymania. Zachowuj dane i uzgadniaj to, co rzeczywiście się dzieje. Powstaje dzięki temu algorytm, którego zachowanie można testować, oceniać i poprawiać bez ukrywania założeń w jednym nieprzejrzystym wyniku lub traktowania niepewnego wysłania jako pozwolenia na rozpoczęcie od nowa.