Look-ahead Bias

QuantConnect opisuje Look-ahead Bias jako podejmowanie decyzji z wykorzystaniem informacji dostępnej dopiero później. Nasze pytanie kontrolne brzmi zatem: co procedura mogła rzeczywiście wiedzieć dokładnie w chwili tej decyzji? Nie wystarczy, że dana odnosi się do tego samego dnia kalendarzowego. Czas zdarzenia, publikacji, otrzymania i wysłania zlecenia może być różny. Dla każdego wejścia trzeba udokumentować dostępność i kolejność operacji; prawidłowo posortowana tabela sama w sobie tego nie dowodzi. [QuantConnect — Custom Securities: Avoid Look-Ahead Bias]

Model czasowy LEAN przekazuje zakończony punkt danych według jego EndTime. Nasz wniosek: ostateczna cena zamknięcia, maksimum, minimum i wolumen całego okresu nie mogą sterować wcześniejszą decyzją wewnątrz tego okresu. Przy wielu interwałach każda seria musi mieć własną regułę dostępności. Przesunięcie wiersza może naprawić konkretny błąd, ale nie zastępuje kontroli stref czasowych, zakończenia okresu i opóźnienia źródła. Użycie już znanej wcześniejszej wartości różni się od użycia późniejszej wartości końcowej aktualnie trwającej świecy. [QuantConnect — Time Modeling: Timeslices]

Dokumentacja FRED odróżnia dostępne dziś informacje o przeszłości od informacji znanych w okresie historycznym; ALFRED pozwala wybrać odpowiedni okres dostępności. Nasz wymóg metodologiczny: pracując z później korygowaną daną, trzeba zachować jej ówczesną wersję i publikację. Data okresu ekonomicznego nie zastępuje daty ogłoszenia. Nawet wersja historyczna sama nie dowodzi dokładnej dostępności w ciągu dnia; tę trzeba zweryfikować osobno. Późniejszej korekty nie można po cichu przenieść do wcześniejszej decyzji. [Federal Reserve Bank of St. Louis — FRED API Real-Time Periods]

scikit-learn wymaga uczenia transformacji wyłącznie na danych treningowych, a następnie stosowania tej samej wyuczonej transformacji do testu. Nasza kontrola czasowa obejmuje normalizację, uzupełnianie braków, wybór cech i cele treningowe. Wynik przyszłego okresu może posłużyć późniejszej ocenie prognozy; nie wolno użyć go do jej wcześniejszego stworzenia ani wyboru reguły. Przy ciągłym ponownym trenowaniu mogą do niego wejść tylko cele już znane w danym momencie. [scikit-learn — Common Pitfalls: Data Leakage]

TradingView wyjaśnia, że jego emulator brokera przy pracy z historycznymi danymi OHLC przyjmuje założenia o ruchu wewnątrz świecy. Nasze rozróżnienie: zapisane maksimum i minimum same nie określają rzeczywistej kolejności wszystkich cen i zleceń. Test musi oddzielić powstanie sygnału, wysłanie zlecenia i możliwą realizację. Wybór wejścia lub wyjścia według później znanego ekstremum jest innym problemem niż jedynie optymistyczny model kosztów. Dokładniejsze dane mogą usprawnić kontrolę, ale nie gwarantują rzeczywistej realizacji. [TradingView — Strategies: Broker Emulator and Lookahead Bias]

Freqtrade porównuje wyniki powtarzanych testów oraz zmiany wskaźników lub sygnałów; zwraca też uwagę na dostęp do przyszłych wierszy i agregacje całej tabeli. Nasz audyt bada więc nie tylko składnię przesunięcia, lecz także pochodzenie każdego obliczenia. Dokumentacja wyraźnie ogranicza kontrolę do sygnałów uruchomionych podczas testu. Czysty wynik narzędzia nie potwierdza niewykonanych gałęzi. Wynik należy czytać razem z pokryciem i ustawieniami symulacji; pewne konfiguracje zleceń z limitem mogą powodować fałszywe alarmy. [Freqtrade — Lookahead Analysis]

TradingView odróżnia Look-ahead Bias od Overfitting, czyli dopasowania reguł do konkretnych danych rozwojowych. Nasz wniosek: nawet czasowo dopuszczalny test może wynikać z rozległego wybierania zwycięzcy. Odwrotnie, prosta reguła może zawierać wyciek przyszłych informacji. Po naprawie trzeba przeliczyć wyniki i zapisać zmianę; nie można zachować pierwotnego zyskownego raportu. Sama różnica między wynikiem historycznym a późniejszym nie wskazuje, czy przyczyną był błąd czasowy, zmiana rynku czy inne założenie. [TradingView — Strategies: Broker Emulator and Lookahead Bias]

NFA wskazuje różnicę między hipotetycznymi wynikami a rzeczywistym handlem. Nasz odtwarzalny zapis zawiera więc wersję danych i reguł, moment dostępności wejść, stan konta, kolejność zleceń i opisane koszty. Audyt musi umieć odtworzyć decyzję wyłącznie z informacji wówczas dostępnych. Paper Trading może dostarczyć kolejnych bieżących zapisów, ale samo nie gwarantuje poprawnego przygotowania danych ani rzeczywistej płynności. Usunięcie wykazanego błędu nie jest obietnicą przyszłej stopy zwrotu. [NFA — Use of Promotional Material Containing Hypothetical Performance Results]