Агент AI-стратегії може побудувати коректний бектест, використовуючи інформацію, якої ще не існувало в момент, коли мали відбутися угоди. Код працює. Крива капіталу виглядає правдоподібно. Сигнал може навіть бути цілком розумним. Та мітка часу, об'єднання таблиць або оновлене поле даних непомітно підказали йому відповідь із завтрашнього дня.
Рішення — зробити час доступності даних частиною дослідницьких вимог. Для кожного вхідного значення потрібно чітко відповісти на 2 запитання: який період воно описує і коли стратегія вперше могла його дізнатися?
Як виглядає упередження заглядання вперед у стратегії, згенерованій AI?
Очевидний випадок — сигнал, розрахований за ціною закриття того самого бару, з виконанням угоди за цією ціною. Якщо для ухвалення рішення стратегії потрібна ціна закриття, вона не може водночас торгувати за цією ціною. Але під час об'єднання джерел даних або вибору зручних значень за замовчуванням агенти часто створюють менш помітні варіанти цієї проблеми.
Уявімо, що модель розраховує ковзне середнє за 20 барами на закритті кожної хвилини й відкриває позицію, коли ціна закриття перетинає середнє. Якщо в бектесті угода виконується за цим самим закриттям, модель використала останню угоду бару ще до того, як ця ціна стала доступною стратегії. Перенесення виконання на відкриття наступного бару може бути прийнятним наближенням, хоча для ринкового ордера все одно треба врахувати комісії та вплив на ринок.
Тепер нехай ознакою буде денний фундаментальний показник акції або знімок відкритого інтересу в криптовалюті. У рядку може стояти дата понеділка, але значення могли опублікувати після закриття торгів у понеділок або виправити пізніше. Дата — це не час доступності.
Як позначати час вхідних даних стратегії?
Якщо джерело це дозволяє, зберігайте щонайменше 3 часові позначки: період, якого стосується значення, час його публікації та час отримання вашою системою. До набору інформації стратегії на момент ухвалення рішення можуть входити лише значення, доступні на той час.
| Поле | На яке запитання відповідає | Типова пастка |
|---|---|---|
| Час події | Коли відбулася ринкова подія? | Використання ціни закриття бару до його завершення |
| Час публікації | Коли джерело опублікувало це значення? | Трактування позначки «кінець дня» як публікації на початку сесії |
| Час завантаження | Коли дослідницька система могла отримати ці дані? | Ігнорування затримки постачальника або конвеєра даних |
| Час перегляду | Коли цю версію записали або виправили? | Завантаження виправленої історії так, ніби вона була початковою |
Для стратегії з інтервалом 1 хвилина затримка в 1 секунду не обов'язково є нешкідливою. Її значення залежить від часу ухвалення рішення та від того, які дані використовує сигнал. Якщо це готова погодинна статистика, затримка може майже нічого не змінити. Якщо це дисбаланс книги ордерів, виміряний незадовго до відправлення ордера, він може змінити напрямок угоди.
Чи може сховище даних на конкретний момент часу запобігти витоку?
Так, якщо «на конкретний момент часу» означає, що можна отримати значення, відоме в історичний момент ухвалення рішення, разом із версією, чинною тоді. Таблиця, у якій просто є історичні дати, усе ще може містити сьогоднішні виправлені значення для цих дат.
Для кожного запису зберігайте інтервал чинності й час доступності та фіксуйте версії, не перезаписуючи їх. Тоді формулюйте історичні запити явно: повертайте останню версію, доступну на момент модельованого рішення. Це особливо важливо для фундаментальних показників, складу індексів, економічних публікацій і наборів даних, очищених постачальником.
Є й непоказний операційний нюанс: ідеальний час публікації нічого не вартий, якщо завдання завантаження даних запустилося із затримкою у 20 хвилин. Якщо історичне сховище не фіксує час завантаження, закладіть консервативну затримку й зазначте це. Точність, якої джерело ніколи не записувало, — лише декорація.
Які перевірки виявляють упередження заглядання вперед до паперової торгівлі?
Попросіть дослідницького агента сформувати разом із бектестом часову шкалу ознак та ордерів. Для кожного рішення записуйте найпізніший час доступності джерела для кожної ознаки, час ухвалення рішення, час відправлення ордера та модельований час виконання. Відхиляйте будь-який рядок, де вхідні дані надійшли після ухвалення рішення.
- Зсуньте сигнали вперед на 1 бар і порівняйте результати. Різке погіршення може свідчити про залежність від таймінгу між закриттями, хоча це лише діагностика, а не доказ витоку.
- Обріжте кожне джерело на історичній контрольній даті, повторно запустіть конвеєр і порівняйте отримані ознаки зі збереженими історичними ознаками.
- Замініть підозрілу ознаку константою. Якщо результати майже не зміняться, перевірте, чи код справді використовував потрібний ряд.
- Передайте через конвеєр навмисно неможливу майбутню ознаку. Перевірка має одразу виявити проблему, якщо час її доступності пізніший за момент ухвалення рішення.
Ці перевірки не сертифікують стратегію. Вони роблять явними конкретні припущення щодо таймінгу й виявляють поширені випадки їх порушення.
Чи доводить паперова торгівля, що в бектесті не було витоку?
Ні. Паперова торгівля може виявити, що робочий потік даних запізнюється, втрачає дані або має інше вирівнювання, ніж історичний. Вона не може довести, що старі навчальні ознаки відображали те, що було відомо на той час. Модель також може перестати отримувати користь від витоку лише тому, що випадково побачене нею майбутнє вже настало.
Використовуйте паперову торгівлю для перевірки узгодженості: порівнюйте поточні значення ознак, часові позначки рішень, формування ордерів і модельовані виконання з визначеннями у бектесті. Якщо вони різняться, простежте конкретний вхідний ряд і часову позначку. Дослідницька команда агентів, яка може пояснити набір інформації для кожного рішення, проводить корисне дослідження. Якщо команда може лише показати вам гладку криву, вона пропустила найскладніший аудит.
← Усі статті
