1. Вихідна точка: мета валідації — не «доведення прибутковості»
Попередні два уроки розглядали, як розподіляти роботу та організовувати вхідні дані. Тепер третій урок перевіряє, чи витримує ідея перевірку часом. Причиною невдач часто стає не хибний напрям, а те, що бектести сприймають як готові висновки без належного аудиту: дані включають вилучені активи, сигнали базуються на майбутніх даних, витрати ігноруються, а параметри підганяють на коротких вибірках. ШІ здатен пришвидшити написання коду та аналіз індикаторів, але не може остаточно вирішити, чи працює стратегія. Справжня мета валідації — за чітко визначених припущень, чи спростовується стратегія статистично або з огляду на витрати, а не доведення, що вона неодмінно приноситиме прибуток завдяки гарній історії.
2. Раціональний розподіл завдань для ШІ в бектестингу
ШІ варто залучати для:
Написання коду фреймворку бектесту
Пояснення коефіцієнта Шарпа, максимальної просадки, відсотка прибуткових угод
Виявлення ймовірних точок упередженості з огляду наперед (look-ahead bias)
Упорядкування результатів у текстові звіти
Людина обов’язково має виконати або перевірити таке:
Чи не містить вибірка лише активи, що вижили (survivorship bias)
Чи існували ціни до моменту лістингу
Чи враховано комісії, прослизання та ставки фондування
Чи проводилися тести на позавибіркових даних або з ковзним вікном (walk-forward)
Чи враховано відмінності між паперовою та реальною торгівлею
Код, який виконується, свідчить лише про те, що інженерний етап завершено, але не про те, що стратегія пройшла валідацію.
3. Очищення даних — найкрихкіший крок криптобектестингу
Якщо бектест використовує лише ті токени, які досі активні, результати будуть систематично оптимістичними. Періоди до лістингу токена не можна вважати придатними для торгівлі. Ціни, обсяги та ставки фондування відрізняються на різних біржах; у бектесті слід зафіксувати біржу або описати правила об’єднання даних. Форки, міграції контрактів і перейменування токенів спричиняють розриви в цінових рядах, які треба виправляти вручну або виключати. Використання одного стейблкоїна для оцінки в періоди депегу (depeg) може викривити показники прибутку та ризику; великі вікна депегу слід окремо позначати чи пояснювати. ШІ має вказувати джерела даних, часові межі та визначення сегменту ринку в документації та звіряти кожен пункт із вихідними даними — це важливіше, ніж просте покращення кривих бектесту.
4. Упередженість з огляду наперед: синхронізація сигналів і виконання
Найпоширеніші вияви такої упередженості:
Використання загальновибіркових статистик для нормалізації, а потім тестування на тій самій вибірці
Генерування сигналів на закритті дня, а виконання — на відкритті наступного
Позначення адрес як «розумні гроші» лише після того, як вони себе виправдали
Використання переглянутих макроданних так, ніби вони були опубліковані історично
Потрібно чітко прописати: сигнали, згенеровані в момент t, мають виконуватися не раніше t+1 залежно від типу стратегії. Якщо макродані неможливо отримати в тому вигляді, в якому вони були оприлюднені, відповідні висновки слід понизити. ШІ може автоматично додавати коментарі до коду про час доступності даних для кожної ознаки; людина має вибірково перевіряти ключові ознаки, щоб вони передували виконанню хоча б на один день.
5. Витрати та тертя: бектести без комісій недійсні за замовчуванням
Криптостратегії мають враховувати щонайменше торгові комісії, прослизання, ставки фондування (якщо позиції перетинають моменти розрахунків), ставки запозичення (якщо використовується плече) та витрати на виведення або крос-чейн операції. Базові й песимістичні сценарії (наприклад, подвійні комісії) дають змогу провести стрес-тестування. Якщо за песимістичних сценаріїв очікувана прибутковість різко падає або стає від’ємною, стратегія дуже чутлива до витрат, і її не можна оцінювати лише за внутрішньовибірковими кривими. ШІ часто ставить комісії за замовчуванням на нуль або один базисний пункт; людина має внести таблиці комісій у припущення бектесту та звіти.
6. Перепідгонка та позавибірковість: чим більше параметрів, тим обережнішою має бути розповідь
Ознаки перепідгонки:
Показ лише найкращої комбінації з багатьох наборів індикаторів
Налаштування параметрів лише на коротких відрізках бичачого ринку
Вузькоспецифічні правила без жодного пояснення, чому вони працюють
Як цьому запобігти:
Виділяти позавибіркові інтервали, які не використовуються для налаштування
Застосовувати тестування з ковзним вікном (walk-forward)
Максимально спрощувати правила, залишаючи їх пояснюваними
Звіти повинні містити ключові метрики як для внутрішньої, так і для позавибіркової вибірки. Якщо позавибіркові результати значно гірші, слід сигналізувати про ризик перепідгонки та призупинити реальне масштабування. ШІ не повинен оптимізувати параметри без контролю, поки крива не виглядатиме добре — це буде автоматизована перепідгонка.
7. Від бектесту до реальної торгівлі: поступове просування замість одноразового запуску
Рекомендується три рівні. Перший: бектест пройдено з чітко описаним сегментом ринку, комісіями та позавибірковими результатами. Другий: паперова або симульована торгівля фіксує розбіжності між сигналом і виконанням та оцінює реальне прослизання. Третій: невеликі реальні угоди з лімітами та стоп-лосами, постійним порівнянням з паперовими результатами. Рішення про перехід на наступний рівень ухвалює людина, а не моделі, що рекомендують великі позиції. ШІ може створювати контрольні списки для кожного рівня, але не може ухвалювати рішення про просування.
8. Мінімальні поля звіту про бектест
Навіть без складних систем звіт має містити:
Одне речення опису стратегії
Часовий діапазон даних та перелік активів
Таблицю припущень про комісії
Віддачу, максимальну просадку та кількість угод у внутрішній і позавибірковій вибірках
Максимальну послідовну втрату
Список невирішених питань
Висновок: продовжити валідацію, призупинити або відмовитися
Уникайте фраз на кшталт «обережно оптимістично», які не дають чітких вказівок до дії. Як до бектестів, так і до оглядів застосовується одне правило: вони мають бути виконуваними, піддаватися аудиту та бути відтворюваними.
9. Підсумок уроку
Цей урок присвячено тому, чи ідеї були перевірені на практиці. ШІ придатний для написання коду бектесту, пояснення індикаторів, виявлення упередженості з огляду наперед та пропущених комісій, але не замінить людину в перевірці упередженості виживання в даних, синхронізації сигналів і виконання, оцінці позавибіркової ефективності чи маржі за песимістичних витрат. Виконання коду та гарні внутрішньовибіркові криві свідчать лише про завершення інженерного етапу, а не про те, що масштабування в реальній торгівлі виправдане. Безпечніший шлях — документувати бектест, потім перевіряти на папері, а вже потім — невеликі реальні спроби; кожен крок ухвалюється людиною. Наступний урок охоплюватиме макроекономічні та основні он-чейн події — періоди, що містять найбільше інформації, але в яких найімовірніше сплутати зведення з висновками. Тому потрібно чітко визначити, де ШІ може допомогти з підготовкою, а де його використання для верифікації є неприпустимим.
