Чому ручне ранжування торгових стратегій не масштабується
Ручний відбір стратегій зазвичай тримається на одному аналітику: він зводить результати прогонів на історичних даних у загальну таблицю, сортує за дохідністю і вручну вирішує, що йде далі. Поки гіпотез десятки, це терпимо.
На сотнях прогонів вузьке місце у відборі стратегій стає головним обмеженням: черга розтягується на тижні, а вердикт залежить від того, хто і в якому порядку дійшов до кандидата.
Окрема проблема — непорівнюваність критеріїв. Метрики рахують на різних періодах, з різними витратами й фільтрами, частину ринкових даних підтягують руками, і зрізи розходяться в часі.
Порівнюються не стратегії, а умови їхніх тестів: сильний кандидат відсіюється через шум у даних, слабкий проходить, бо потрапив у вдале вікно.
Третя втрата — історія рішень. Ранжування торгових стратегій живе в листуванні й особистих файлах: причина відхилення не зафіксована, правила відбору не версіонуються, повторюваність не перевіряється.
Через місяць ніхто не відповість, чому стратегія зі схожими показниками була прийнята, а інша ні, — і масштабування відбору гіпотез знову впирається в одну людину.
Підсумок передбачуваний: швидкість відбору зростає повільніше за число гіпотез, а ціна помилки — робоча позиція, зібрана на перенавченому кандидаті.
Розбираємо, як це закривається: де поставити формальні критерії, як привести джерела до одного зрізу і чому вердикт має відтворюватися.
Ефект від впровадження: швидкість відбору та стійкість результату
Ручний відбір кандидатів упирається в стіну: щоб порівняти кілька десятків наборів правил, аналітик проганяє їх по черзі, вручну зводить метрики в таблицю і на око виставляє ваги.
Один цикл займає тижні, а результат наступного прогону не збігається з попереднім — кандидат проходить або відсіюється через зміну порядку перевірки, а не через якість стратегії.
Система ранжування рахує всіх кандидатів одним пакетним прогоном і сортує за зведеним балом.
Швидкість відбору кандидатів скорочується з тижнів до годин, а частка слабких варіантів, які автоматично відсіюються за порогом, сягає дев’яти з десяти — до ручного розбору доходять одиниці, і на них вистачає часу.
Відтворюваність результатів відбору дає версіонування наборів правил: прогін прив’язаний до версії набору, зрізу даних і зафіксованим вагам.
Повторний запуск на тому самому зрізі видає ідентичний ранжований список, тому суперечка «чому ця стратегія вище» вирішується порівнянням двох версій, а не розбором логів. Журнал прогонів ведемо в MLflow.
Зниження хибних спрацювань іде завдяки відмові від ручного налаштування ваг: зникає клас помилок на перенавчених кандидатах, які гарно виглядають на короткому відрізку й розвалюються на наступному.
Ваги рахуються з історичних прогонів із перевіркою на відкладеному періоді, тому така стратегія отримує низький бал до потрапляння в портфель.
Підсумок — передбачуваний конвеєр: прогін, автоматичний відсів, розбір залишку. Швидкість відбору й стійкість результату стають параметрами кожного запуску, а не залежать від того, хто саме зводив таблицю.
Режими роботи системи: пакетний, потоковий і гібридний
Схему розрахунку вибирають за двома параметрами: як часто потрібен перерахунок ранжування торгових стратегій і наскільки свіжою має бути оцінка на момент рішення.
Від цього залежить, чи рахуємо ми рейтинг за закриттям періоду, оновлюємо його в міру надходження даних або поєднуємо обидва підходи.
Пакетний перерахунок відтворюваний: однаковий вхід дає однаковий рейтинг, будь-яку оцінку можна пояснити й відкотити.
Потокова обробка ринкових даних скорочує затримку між зміною ринку й оновленням позиції стратегії, але частина розрахунків залежить від порядку надходження подій, і повторити минулий результат складніше.
Гібридна схема розрахунку знімає цю суперечність: важкий перерахунок іде за розкладом, потік дописує лише швидкі поправки.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Пакетний перерахунок | Періодичні рішення, важливіша пояснюваність і повторюваність оцінки | Рейтинг застаріває до кінця інтервалу, пікові навантаження на розрахунковий контур |
| Потокова обробка | Рішення ухвалюється на русі ринку, затримка критична | Складніше відтворити минулий результат, вищі вимоги до контролю якості даних і моніторингу |
| Гібридна схема | Потрібні і свіжість, і стійка база для звітності та розбору спірних випадків | Два контури: дорожче в розробці й супроводі, потрібне узгодження станів і перевірки збіжності |
Обмеження режимів проявляються не відразу, а при зростанні числа стратегій і джерел даних — тому режим закладають на етапі проєктування, а не змінюють заднім числом.
Ми описуємо обидва контури та правила їхнього узгодження заздалегідь: тоді перехід від пакетного перерахунку до гібридного стає налаштуванням, а не переписуванням моделі.
Етапи впровадження: від аудиту даних до передачі в експлуатацію
Ранжування торгових стратегій ламається не на моделі, а на вході: пропуски в котируваннях, різні таймфрейми й делістинговані інструменти дають гарний результат, який не відтворюється. Тому етапи йдуть строго послідовно — до розрахунків не переходимо, поки попередній шар не прийнято.
- Аудит ринкових даних. Звіряємо джерела, глибину історії та повноту інструментів, позначаємо розриви сесій, спліти й делістинги — інакше критерії відбору зміщені до паперів, що вижили.
- Критерії відбору. Фіксуємо, за чим ранжуємо: дохідність з поправкою на ризик, стійкість до просадки, витрати обороту; кожен критерій отримує вагу й правило розрахунку.
- Схема ознак. Описуємо ознаки з цін, обсягів і волатильності, їхні вікна й нормалізацію — так результат пояснюваний, а не отриманий перебором варіантів.
- Контури розрахунку. Розділяємо зберігання рядів і шар обчислень: агрегати й тикові зрізи лежать у ClickHouse, перерахунок після правки ознак займає хвилини, а не ніч.
- Перевірка на історичних даних. Проганяємо стратегії на відкладеному періоді, перевіряємо стійкість рангів до зміни вікна й комісій; ті, що втрачають місце при зсуві, до рейтингу не потрапляють.
- Приймання системи. Спільно з вашою командою звіряємо ранги на контрольній вибірці, розбираємо розбіжності й фіксуємо версію моделі.
- Передача в експлуатацію. Віддаємо конфігурації, регламент перерахунку, моніторинг якості даних і навчання ваших аналітиків.
Критерій готовності один: той самий набір даних і параметрів дає той самий рейтинг, а падіння якості котирувань видно в моніторингу раніше, ніж у торгових результатах.
Комплект постачання: конфігурації, схеми ознак і регламенти
Замовник отримує не підсумковий звіт, а робочий контур: набір конфігурацій, описів і регламентів, за якими ваша команда сама керує ранжуванням торгових стратегій, не звертаючись до нас за кожною правкою. Кожен артефакт прив’язаний до свого місця в процесі — від підготовки даних до розбору розбіжностей.
- Конфігурації системи — файли параметрів: ваги факторів, горизонти й частота перерахунку, пороги відсікання, правила обробки пропусків. Редагуються без перезбирання, кожна версія зберігається, повернення до попередньої — одна команда.
- Схема ознак — для кожного показника зазначено, з якого джерела він розраховується, яке вікно агрегації використовується, як обробляються викиди і чому набір ознак саме такий.
- Політики доступу — ролі аналітика, трейдера і ризик-контролю, право змінювати ваги й пороги, журнал змін з автором і причиною.
- Регламент перерахунку — розклад запусків, порядок кроків, точки контролю якості та дії при розбіжності результату з перевіркою на історичних даних.
- Метрики якості ранжування — що вважаємо стійкістю, які відхилення визнаємо деградацією і за яких умов запускається перегляд ваг.
- Документація — інструкції з розгортання, опис конфігурацій і схеми даних, розбір типових збоїв і порядок дій.
- Передача команді — розбір контуру з вашими інженерами й аналітиками, відповіді на запитання щодо кожного артефакту.
Приклад із практики: як змінився відбір після впровадження
До впровадження відбір торгових стратегій тримався на ручній перевірці: три аналітики проганяли через Backtrader близько сорока гіпотез на тиждень і відхиляли кандидатів за інтуїцією, звіряючись із розрізненими показниками в таблицях.
Повний цикл відбору займав два-три тижні, а самі рішення майже не фіксувалися — пояснити відмову через місяць або повторити чужий висновок було нічим.
Що змінили
Ми описали кожну гіпотезу набором ознак: поведінку дохідності в різних ринкових режимах, чутливість до зсуву вхідних даних, кореляцію з уже працюючими стратегіями, стабільність після зміни періоду перевірки.
Модель ранжування будує впорядкований список з оцінкою впевненості, і аналітик розбирає верхні п’ятнадцять-двадцять позицій замість усього потоку — ручна робота змістилася туди, де справді потрібне рішення людини.
Що стало
Частка слабких кандидатів, відсіяних автоматично до ручного розбору, тримається на рівні близько 80%, а цикл відбору скоротився з двох-трьох тижнів до двох діб: прогін і ранжування йдуть уночі, уранці команда отримує готовий список з обґрунтуванням за кожною ознакою.
Стійкість результату зросла помітніше за швидкість: частка стратегій, що зберегли показники на даних поза навчальним вікном, піднялася приблизно з 15% до 40%.
Причина не в самій моделі, а в тому, що раніше слабкі гіпотези відрізнялися від сильних лише на довгій дистанції — тепер вони відсікаються до того, як у них вкладуть час розробки й супроводу.
Чим ранжування відрізняється від ручного сортування?
Ручне сортування працює, поки кандидатів десяток: експерт тримає в голові дохідність, просадку й загальну логіку підходу та вибирає за досвідом.
На двох сотнях варіантів порядок починає залежати від того, хто переконливіше сперечається, а не від якості стратегії: той самий набір при повторному розборі вибудовується інакше, бо критерії ніде не зафіксовані.
Формальне ранжування торгових стратегій рахує вагу кандидата як зважену суму нормованих показників.
Крім дохідності в оцінку входять просадка, стійкість результату на різних режимах ринку, витрати на угоду, оборот і кореляція з уже працюючими стратегіями — без цього у верхівку рейтингу потрапляють десять копій одного й того самого підходу, а диверсифікація втрачається.
Ваги й пріоритети оголошуються до перегляду результатів. У ручному режимі критерії мимоволі підбираються під уже вподобану стратегію, у формальному — порядок обчислюється із заздалегідь заданих правил, і правка ваги видна всій команді, а не залишається в голові одного експерта. Це дає змогу перерахувати рейтинг тим самим способом на новому зрізі даних.
Пояснюваність рішень дає внесок кожного показника в підсумковий бал: видно, що кандидат на п’ятому місці через глибоку просадку, а не через слабку дохідність.
Суперечка переходить з «мені здається, ця краща» на «чи піднімаємо вагу стійкості» — обговорюється одна вага замість двох сотень кандидатів. Рішення залишається відтворюваним за журналом прогону, і його можна переперевірити, а не відновлювати з пам’яті.
Технічні сумніви: дані, режими ринку, пояснюваність
Ранжування стратегій ламається не на моделі, а на даних і на ознаках того, що ринок змінив характер. Нижче — чотири питання, які найчастіше виринають на технічних обговореннях.
Історії мало — модель взагалі можна навчати?
Нестачу закриваємо не збільшенням довжини, а структурою. Ріжемо історію на незалежні вікна, навчаємо на дальших, перевіряємо на наступних і рахуємо метрику ранжування окремо за кожним вікном.
Якщо розкид між вікнами великий — сигнал слабкий, і це видно до виведення системи в роботу. Плюс розширюємо набір ознак: не лише ціна, а й ліквідність, волатильність, сезонність, тому кожне спостереження починає нести більше інформації.
Як система переживає зміну режиму ринку?
Режим описуємо явними спостережуваними величинами — тренд проти боковика, широка чи вузька волатильність, стійкість спреду. Ранжування будується окремо всередині режиму, а не однією універсальною формулою.
Коли статистика режиму виходить із звичних меж, ваги перераховуються і частка капіталу під стратегію знижується автоматично, без ручного втручання.
Чому стратегія опинилася вище — це пояснювано?
Для кожної позиції в списку зберігаємо внесок ознак у підсумковий бал. Замовник бачить, що саме підняло стратегію і що її обмежує, а не абстрактне «модель порахувала».
Це ж слугує інструментом контролю: якщо вага ознаки розходиться зі здоровим глуздом, ми це знаходимо на етапі перевірки, а не після просадки.
Обов’язково одразу запускати все?
Ні, ідемо поетапно. Спочатку офлайн-контур: дані, ознаки, ранжування, звіти зі стійкості. Потім — робота на історичних даних у режимі, близькому до живого, зі щоденним порівнянням прогнозу й факту.
І лише після цього — обмежена частка капіталу й поступове розширення списку та обсягу, за заздалегідь заданими критеріями зупинки.
З чого почати: які дані та доступи знадобляться
Щоб підготовка до обговорення не розтяглася на тижні листування, нам потрібен конкретний набір вхідних даних, доступів і обмежень.
Чим точніше ви опишете, як рішення щодо стратегій ухвалюються зараз, тим менше припущень ми закладемо в ранжування і тим реалістичнішим буде план робіт.
- історичні ряди: угоди, котирування й дані про ліквідність за період, що покриває різні режими волатильності;
- каталог стратегій: правила входу й виходу, параметри ризику, версія й авторство кожної;
- журнали фактичного виконання: реальні ціни, просковзування, відмови, затримки;
- доступи до даних: вивантаження або читання зі сховища, доступ до торгового контуру в тестовому режимі без права виведення коштів;
- обмеження: які метрики й горизонти вважаються прийнятними, що заборонено враховувати в ранжуванні;
- регламент: хто ухвалює рішення за підсумками ранжування і чи потрібна пояснюваність за кожною стратегією;
- відповідальні з вашого боку: власник даних і той, хто підтвердить коректність історичних рядів.
Прогалини в даних не блокують старт — частину закриваємо на етапі підготовки, і ми скажемо прямо, де саме.
Далі збираємо пілотний контур: проганяємо ранжування торгових стратегій на вашій історії, звіряємо порядок із рішеннями, які ви вже ухвалювали, і показуємо, де модель розходиться з поточною практикою. Опишіть задачу й надішліть те, що є, — повернемося з оцінкою, складом етапів і планом робіт.
