601 / 691LOOK

Look-ahead Bias

Викривлення через використання майбутньої інформації

Look-ahead Bias виникає, коли історичне рішення використовує інформацію, яка тоді ще не була доступна. Помилка може ховатися в часовій мітці, завершеній свічці, переглянутій базі даних або підготовці моделі. Тоді добрі ретроспективні результати не описують процедуру, яку можна було здійснити в той момент.

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]

ПрикладПРИКЛАД · LOOK

Прибуток від знання майбутнього не є доступною стратегією

Наша вигадана модель має чотири послідовні періоди A, B, C і D. Ціни відкриття становлять [100, 100, 100, 100] USD/BTC, а ціни закриття — [110, 90, 120, 80] USD/BTC. Попередній завершений період перед A мав відкриття й закриття на рівні 100 USD/BTC. Кожний рахунок починає з 1000 USD без позиції, боргу та зовнішніх грошових потоків. Під час входу він купує фіксовано 1 BTC за модельною ціною відкриття, а заздалегідь визначений вихід продає його на закритті того самого періоду. Комісія становить 1 USD за кожну сторону виконаної угоди; без входу комісії немає. Інші витрати та Slippage в цій моделі не враховуємо. Помилковий варіант X купує лише тоді, коли вже знає, що закриття періоду, який щойно починається, буде вище за його відкриття. Його входи — [1, 0, 1, 0], а чисті результати — [8, 0, 18, 0] USD. Сума становить 26 USD, кінцеві грошові кошти — 1026 USD. Часово допустимий варіант Y застосовує ту саму умову зростання, але лише до попереднього завершеного періоду. Його входи — [0, 1, 0, 1], а чисті результати — [0, -12, 0, -22] USD. Сума становить -34 USD, кінцеві грошові кошти — 966 USD. Обидва варіанти після кожного періоду мають нульову позицію. Графік порівнює чисті результати X і Y в окремих періодах. Варіант X використовує майбутній показник для ранішого рішення; тому його прибуток не є здійсненним доказом переваги. Збиток Y не оцінює результат реального ринку й не стверджує, що правильна часова послідовність завжди призводить до збитку. Модельні ціни не є історичними цінами Bitcoin, а припущене виконання не гарантує фактичного виконання.

Для повної картини прочитайте також Backtesting, Overfitting, Walk-forward Analysis, Survivorship Bias, Paper Trading. На цю статтю також посилаються Walk-forward Analysis, Overfitting, Survivorship Bias, On-chain Analysis.

01Чи достатньо зсунути всі індикатори на один рядок?

Ні. Зсув може усунути конкретне використання майбутнього значення, але автоматично не виправляє часові пояси, затриману публікацію, перегляди чи підготовку даних. Вирішальною є підтверджена доступність кожного входу у відповідний момент.

02Чи завжди використання майбутнього результату під час оцінювання є помилкою?

Ні. Пізніше встановлений результат потрібний для оцінювання раніше створеного прогнозу. Помилка виникає, якщо ця майбутня інформація потрапляє до його ранішого рішення, навчання чи вибору правила.

DOC · 001QuantConnect — Time Modeling: TimeslicesДокументація ↗DOC · 002QuantConnect — Custom Securities: Avoid Look-Ahead BiasДокументація ↗DOC · 003Federal Reserve Bank of St. Louis — FRED API Real-Time PeriodsДокументація ↗DOC · 004scikit-learn — Common Pitfalls: Data LeakageДокументація ↗DOC · 005TradingView — Strategies: Broker Emulator and Lookahead BiasДокументація ↗DOC · 006Freqtrade — Lookahead AnalysisДокументація ↗DOC · 007NFA — Use of Promotional Material Containing Hypothetical Performance ResultsДокументація ↗
Спочатку джерела · Не інвестиційна порада