Look-ahead Bias — це часова помилка оцінювання, коли інформацію, доступну пізніше, використовують для попереднього рішення, навчання чи вибору правила. Саме по собі пізніше вимірювання результату вже зробленого прогнозу не є такою помилкою.
QuantConnect описує Look-ahead Bias як ухвалення рішень з інформацією, що стала б доступною лише пізніше. Тому наше контрольне запитання таке: що процедура справді могла знати саме під час цього рішення? Недостатньо, щоб показник належав до того самого календарного дня. Час події, публікації, отримання та надсилання ордера може відрізнятися. Для кожного входу потрібно підтвердити доступність і порядок операцій; правильно відсортована таблиця сама по собі цього не доводить. [QuantConnect — Custom Securities: Avoid Look-Ahead Bias]
Часова модель LEAN передає завершену точку даних відповідно до її EndTime. Наш висновок: остаточна ціна закриття, максимум, мінімум та обсяг усього періоду не повинні керувати ранішим рішенням усередині цього періоду. За кількох часових масштабів кожний ряд має мати власне правило доступності. Зсув рядка може виправити конкретну помилку, але не замінює перевірки часових поясів, завершення періоду й затримки джерела. Використання вже відомого попереднього значення відрізняється від використання пізнішого остаточного значення поточної свічки. [QuantConnect — Time Modeling: Timeslices]
Документація FRED розрізняє доступну сьогодні інформацію про минуле та інформацію, відому в історичний період; ALFRED дозволяє обрати відповідний період доступності. Наша методична вимога: якщо показник пізніше виправляють, треба зберегти його тодішню версію та її публікацію. Дата економічного періоду не замінює дату випуску. Навіть історична версія сама по собі не підтверджує точну внутрішньоденну доступність; її слід перевіряти окремо. Пізніше виправлення не можна непомітно повернути до ранішого рішення. [Federal Reserve Bank of St. Louis — FRED API Real-Time Periods]
scikit-learn вимагає навчати перетворення лише на навчальних даних, а потім застосовувати те саме навчене перетворення до тесту. Наша часова перевірка охоплює нормалізацію, заповнення пропусків, відбір ознак і навчальні цілі. Результат майбутнього періоду може слугувати для пізнішого оцінювання прогнозу; його не можна використовувати для ранішого створення прогнозу чи вибору правила. За поточного повторного навчання до нього можуть входити лише цілі, вже відомі на відповідний момент. [scikit-learn — Common Pitfalls: Data Leakage]
TradingView пояснює, що його брокерський емулятор використовує припущення про рух усередині свічки, працюючи з історичними OHLC-даними. Наше розрізнення: зафіксовані максимум і мінімум самі не визначають фактичного порядку всіх цін та ордерів. Тест має розділяти виникнення сигналу, надсилання й можливе виконання. Вибір входу чи виходу за пізніше відомим екстремумом — інша проблема, ніж просто оптимістична модель витрат. Докладніші дані можуть уточнити перевірку, але не гарантують реального виконання. [TradingView — Strategies: Broker Emulator and Lookahead Bias]
Freqtrade порівнює результати повторних тестів та зміни індикаторів чи сигналів; також попереджає про доступ до майбутніх рядків і агрегування всієї таблиці. Тому наш аудит вивчає не тільки синтаксис зсуву, а й походження кожного обчислення. Документація прямо обмежує перевірку сигналами, які спрацювали під час тесту. Чистий результат інструмента не підтверджує неперевірені гілки. Результат треба читати разом із покриттям та налаштуваннями симуляції; деякі конфігурації лімітних ордерів можуть спричинити хибні спрацювання. [Freqtrade — Lookahead Analysis]
TradingView відрізняє Look-ahead Bias від Overfitting, тобто підлаштування правил під конкретні дані розробки. Наш висновок: навіть часово допустимий тест може бути результатом масштабного відбору переможця. І навпаки, просте правило може містити витік майбутньої інформації. Після виправлення треба перерахувати результати й зафіксувати зміну; залишати початковий прибутковий звіт не можна. Сама різниця між історичним і подальшим результатом не вказує, чи причиною була часова помилка, зміна ринку або інше припущення. [TradingView — Strategies: Broker Emulator and Lookahead Bias]
NFA звертає увагу на відмінність гіпотетичних результатів від реальної торгівлі. Тому наш відтворюваний запис містить версію даних і правил, момент доступності входів, стан рахунку, послідовність ордерів та описані витрати. Аудит має вміти відтворити рішення лише з тоді доступною інформацією. Paper Trading може додати поточні записи, але сам по собі не гарантує правильності підготовки даних чи реальної ліквідності. Усунення доведеної помилки не є обіцянкою майбутньої дохідності. [NFA — Use of Promotional Material Containing Hypothetical Performance Results]
Прибуток від знання майбутнього не є доступною стратегією
Для повної картини прочитайте також Backtesting, Overfitting, Walk-forward Analysis, Survivorship Bias, Paper Trading. На цю статтю також посилаються Walk-forward Analysis, Overfitting, Survivorship Bias, On-chain Analysis.
01Чи достатньо зсунути всі індикатори на один рядок?+
Ні. Зсув може усунути конкретне використання майбутнього значення, але автоматично не виправляє часові пояси, затриману публікацію, перегляди чи підготовку даних. Вирішальною є підтверджена доступність кожного входу у відповідний момент.
02Чи завжди використання майбутнього результату під час оцінювання є помилкою?+
Ні. Пізніше встановлений результат потрібний для оцінювання раніше створеного прогнозу. Помилка виникає, якщо ця майбутня інформація потрапляє до його ранішого рішення, навчання чи вибору правила.