Розробка системи A/B-тестування торгових моделей

A/B тестування торгових моделей: де ламається порівняння

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

Ключова пастка — перетин угод. Якщо моделі відкривають позиції за одним інструментом майже одночасно, їхні результати корелюють, і різниця між ними йде в розкид виконання. Спостережувана перевага залишається в межах похибки, хоча виглядає переконливо.

Без оцінки статистичної значущості результату не можна відокремити стійку перевагу від випадкового відхилення.

Дивляться не на підсумкову цифру, а на розподіл дохідностей, кількість незалежних спостережень і поведінку за зсуву стартової дати: модель, що виграє в одному вікні, зазвичай не виграє в жодному іншому.

Окремо розбирають просідання стратегії. Дві моделі з близькою дохідністю дають різну глибину й тривалість просідання, а іноді й різну його природу — ринкову чи технічну, пов'язану з відмовами виконання й затримками даних. За однією кривою дохідності цього не побачити.

Замикає картину помилка того, хто вижив: з десятка перевірених варіантів у роботу потрапляє той, що випадково показав найкращий результат на історії. Під час порівняння пар це небезпечніше вдвічі — перебір пар майже гарантує «переможця», у якого немає причин працювати далі.

Тому стенд розводить моделі за незалежними потоками даних, фіксує гіпотезу до запуску й ураховує множинність порівнянь — розбираємо, як це влаштовано.

Що дає керований контур порівняння моделей

Контур порівняння будується навколо контрольної групи: потік сигналів розділяється детерміновано — за ключем з ідентифікатора інструмента й часу входу, — тому модель-кандидат і еталонна модель отримують однакові ринкові умови.

Розділення потоку фіксує частку відсічених сигналів, і розбіжність у результаті пояснюється логікою моделі, а не різною вибіркою угод. Без цього A/B-порівняння торгових моделей вироджується в суперечку про те, чий період був вдаліший.

Журнал експериментів зберігає все, що визначає прогін: зріз даних, параметри ризику, версію моделі, вхідні ряди й налаштування виконання.

Запуск повторюється за місяць на тому самому зрізі й дає той самий результат — повторюваність перестає залежати від пам'яті інженера й локальних копій файлів.

Для журналу беремо MLflow: метрики, артефакти й параметри прив'язані до конкретного запуску, і будь-який висновок можна переперевірити.

Цикл перевірки гіпотези стискається: кандидат проходить порівняння на історичній і відкладеній ділянках, не виходячи в реальну торгівлю.

Раніше на одну перевірку йшли тижні очікування статистики, тепер — години роботи контуру, а кількість перевірених гіпотез зростає за того самого складу команди. Гіпотеза, що не пройшла контрольну групу, відсікається до того, як займе капітал.

Окремо зникає клас помилок «модель обрано випадково». Рішення ухвалюється, тільки якщо перевага перевищує розкид, стійка на кількох ділянках і не зникає за зсуву старту.

Частка моделей, відхилених на цьому кроці, показує, скільки разів попередній відбір пропускав у роботу статистичний шум.

Формати порівняння: живий запуск, реплей, тіньовий режим

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

Реплей і тіньовий режим дозволяють помилятися без наслідків — натомість вимагають підготовленого архіву й окремого контуру спостереження.

Умови застосовності диктують обсяг і якість архівних даних, ліквідність інструмента й те, наскільки оборотне рішення.

Де який формат доречний

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

Етапи впровадження контуру порівняння моделей

Контур порівняння торгових моделей — це відтворюваний експеримент: одна ринкова історія, однакові правила виконання заявок і різна логіка ухвалення рішень.

Сенс у тому, щоб різниця в результаті пояснювалася самою моделлю, а не особливостями вибірки, моменту запуску чи налаштувань рахунку. Робота йде послідовно — від розбору даних до передачі контуру команді замовника.

1. Розбір даних і постановка гіпотези. Перевіряємо, які ряди, угоди й сигнали є в наявності, як вони розмічені, де пропуски й викиди. Формулюємо, який саме ефект перевіряємо і що вважаємо поліпшенням результату.
2. Схема експерименту й розмітка груп. Визначаємо контрольну й тестові групи, правила їх формування, вікно спостереження й критерії дострокової зупинки, щоб порівняння не підганялося під результат.
3. Налаштування збору метрик. Фіксуємо єдиний набір показників на угоду й на період: дохідність, просідання, кількість спрацювань, частка відхилених сигналів. Логи пишуться однаково для всіх груп — інакше порівняння втрачає сенс.
4. Перевірка на архівних зрізах. Прогоняємо контур на історичних даних кількома незалежними відрізками, включно зі спокійними й волатильними ділянками. Дивимося, чи стійкий відрив між групами, чи він тримається на одному вдалому періоді.
5. Контроль викривлень. Прибираємо вплив випадковості: повторюємо прогони з різними початковими умовами, звіряємо розподіл результатів груп. Модель допускається до роботи тільки за відтворюваної переваги.
6. Передача команді. Віддаємо конфігурації груп, скрипти запуску, опис метрик і регламент додавання нових моделей. Інженери замовника проводять наступний прогін самостійно, ми залишаємося на зв'язку щодо спірних випадків.

Такий порядок дає головне: результат порівняння можна переперевірити в будь-який момент і повторити без нас.

Що залишається в команди: конфігурації, схеми, регламенти

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

Тому разом із системою передаємо комплект артефактів — кожен версіонується у вашому репозиторії й оновлюється за звичайною процедурою перевірки змін.

• Конфігурація контуру — середовища, черги, сховища й параметри запуску моделей. За нею контур піднімається на новому майданчику без наших інженерів.
• Карта експериментів — які гіпотези перевіряються, які групи порівнюються і як довго триває замір. Видно, які тести вже закриті, а які перетинаються й заважають одне одному.
• Правила розмітки — що вважається коректною угодою, які записи відкидаються і чому. Єдині для всіх моделей, тому результати зіставні між звітами.
• Регламент зупинки — умови аварійного припинення тесту: просідання через прослизання, розбіжність очікуваної й фактичної дохідності, відмова джерела даних. Прописано, хто ухвалює рішення і що відбувається з відкритими позиціями.
• Документація щодо метрик — формули розрахунку, вікна усереднення, обробка викидів і комісій. Одна метрика не рахується двома способами в різних звітах.
• Схема ролей і доступів — хто змінює параметри, хто зупиняє тест, хто бачить проміжні результати. Плюс процедура відкату конфігурації до попередньої версії.

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

Кейс: скоротили цикл вибору моделі втричі

Замовник — команда кількісних стратегій, яка обирала торгові моделі майже вручну.

Черга гіпотез зростала, а цикл перевірки однієї займав 3–4 тижні: половина часу йшла на перезбирання середовища й розбір розбіжностей, коли два аналітики на одному наборі даних отримували різні числа.

У реальну торгівлю йшли 4 моделі з 10, і кожна друга з них відкочувалася — рішення ухвалювали за середнім результатом, без оцінки розкиду.

Що змінили

Зібрали єдиний контур A/B-тестування: маніфест запуску фіксує версію набору даних, хеш коду, параметри стратегії й розмір груп, тому будь-який прогін повторюваний.

Історична перевірка й тест на живому ринку йдуть одним маршрутом через Airflow, групи порівнює один модуль статистики — з довірчими інтервалами, а не середніми. Усі запуски пишуться в журнал: видно, хто, що і на яких даних перевіряв.

Що стало

Цикл перевірки гіпотези скоротився з 3–4 тижнів до 5–7 днів, і вузьке місце змістилося з підготовки середовища на формулювання самої гіпотези. Частка відкатів після виходу в торгівлю впала з 40% до 12%: моделі з широким розкидом відсіюються до запуску, а не після втрат.

Повторний прогін на тому самому маніфесті дає ідентичний результат у 100% випадків, тоді як раніше розбіжності траплялися майже в кожному третьому прогоні. Вибір моделі перестав залежати від того, хто саме рахував.

Що робити, якщо кілька моделей уже працюють на одному рахунку?

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

Розведення моделей роблять на трьох рівнях, і вибір залежить від того, наскільки строго потрібно ізолювати результати.

Покроковий перехід займає одну-дві торгові сесії й не вимагає зупинки торгівлі. Спершу вмикається мітка угод і тіньовий журнал — на цьому кроці нічого не змінюється, лише накопичується розріз за кожною моделлю.

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

Збереження робочого контуру тримається на фіксації базових метрик до змін: частка прибуткових угод, максимальне просідання, середній час утримання позиції. Якщо після виносу розріз розходиться з тіньовим журналом, ваги повертаються конфігурацією, без викочування нового коду.

У контурі Ethereum виконання фіксується на окремих адресах, тому історія угод залишається перевірюваною й не переписується заднім числом.

Технічні питання: значущість, дані, відкат

Запуск тесту торгової моделі впирається в три речі: чи вистачає історії, чи значуща різниця між варіантами і як повернутися назад, якщо гіпотеза не підтвердилася. Нижче — відповіді на інженерні сумніви, які спливають до старту.

Як перевіряєте достовірність різниці?

Дохідність розподілена нерівномірно — рідкісні великі угоди переважують довгу серію дрібних. Тому порівнюємо розподіли перестановочним тестом, даємо довірчий інтервал і поправку на множинні порівняння, коли перебираємо багато наборів параметрів.

Що означає відкат експерименту і скільки він займає?

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

Як якість даних впливає на результат?

Пропуски котирувань, розриви історії й розбіжності торгових календарів дають хибний приріст дохідності, який зникає на живому ринку. Дані звіряємо за незалежним джерелом і позначаємо ділянки з неповною історією.

Які викривлення шукаєте окремо?

Заглядання в майбутнє — ознака, порахована за закриттям того самого бару, відбір за інструментами, що вижили, різна ліквідність між варіантами. Кожне перевіряємо окремим сценарієм: прогоняємо модель на даних із затримкою сигналу.

Обговоримо задачу: що надіслати для оцінки

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

Надішліть те, що вже є в будь-якому вигляді: скрипти, таблиці, вивантаження журналів — розберемося самі.

• Як зараз порівнюються версії моделі: ручні прогони, набір скриптів чи власна обв'язка — і скільки часу займає один повний цикл порівняння.
• Опис торгової логіки: які параметри змінюються між версіями, а які вважаються фіксованими й не повинні потрапляти в експеримент.
• Дані: глибина історії котирувань, інтервали, джерела, наявність поділу на навчальний і перевірний періоди та правило, за яким обрано межу.
• Правила розрахунку результату: набір метрик (дохідність, максимальне просідання, профіт-фактор, частка прибуткових угод), урахування комісій і прослизання.
• Журнали одного повного циклу: угоди, сигнали, відмови від входу, лог помилок — за ними видно, де втрачається зіставність прогонів.
• Обмеження ризику: ліміти на позицію, денні стопи, правила зупинки тесту за виходу за задані межі.
• Контур виконання: тестовий рахунок, пісочниця брокера чи робочий рахунок малим обсягом, і як результати повертаються у звіт.
• Хто на вашому боці ухвалює рішення про переведення моделі в робочий режим і за якими критеріями.

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