Ви провели backtest стратегії — 40% річних при просадці 15%. Через місяць реального рахунку — мінус 30% капіталу. Знайомо? Історичний backtest показує лише одну реалізацію. Щоб побачити повний спектр можливих результатів, потрібна Monte Carlo симуляція. Ми розробляємо систему, яка відповідає на питання, недоступні звичайному backtest: яка ймовірність втратити 20% капіталу за півроку, чи витримає стратегія затяжний drawdown.
На відміну від одиничного історичного шляху, Monte Carlo генерує тисячі альтернативних сценаріїв з тих самих трейдів, даючи ймовірнісну оцінку дохідності та ризику. Наприклад, при 10 000 симуляцій ви отримуєте розподіл дохідності: медіанне значення 40%, але 5-й процентиль — мінус 20%. Це змінює підхід до управління капіталом. Такий аналіз незамінний для хедж-фондів, проп-трейдерів та приватних інвесторів, які бажають зрозуміти реальні ризики.
Навіщо Monte Carlo для торгівлі
Єдина backtest-крива — випадковість. Історичний backtest — один реалізований шлях з нескінченної кількості можливих. Трейди траплялися в конкретному порядку, за конкретної ринкової волатильності. Monte Carlo симуляція багаторазово перемішує трейди або генерує нові зі статистичної моделі, створюючи розподіл можливих результатів.
Ключові результати, які ви отримуєте:
- Довірчий інтервал для очікуваної дохідності (5-й, 50-й, 95-й процентилі)
- Ймовірність конкретного рівня drawdown (наприклад, 20%)
- Необхідний початковий капітал для виживання з імовірністю 95%
- Очікуваний час до відновлення після просадки
Які методи Monte Carlo ми використовуємо?
Ми застосовуємо два основні підходи: рандомізацію трейдів та параметричне моделювання. Рандомізація проста і не потребує припущень про розподіл, але не враховує часові залежності. Параметричні моделі, такі як GBM або Student-t, краще екстраполюють, але вимагають підбору розподілу. Вибір методу залежить від ваших даних та цілей. Іноді ми використовуємо машинне навчання для оцінки параметрів розподілу.
| Метод |
Переваги |
Недоліки |
| Рандомізація трейдів |
Не потребує прип. про розподіл |
Не враховує часові залежності |
| Параметричне моделювання |
Враховує fat tails, екстраполяція |
Потребує підбору розподілу |
Randomization по трейдам — найпростіший підхід: перемішування історичних трейдів з поверненням.
import numpy as np
import pandas as pd
def monte_carlo_randomize_trades(trade_returns, n_simulations=10000, n_periods=252):
"""
trade_returns: масив дохідностей кожної угоди
Кожна симуляція — випадкова вибірка з поверненням
"""
results = np.zeros((n_simulations, n_periods))
for i in range(n_simulations):
sampled_trades = np.random.choice(trade_returns, size=n_periods, replace=True)
results[i] = np.cumprod(1 + sampled_trades) - 1
return results
equity_curves = monte_carlo_randomize_trades(historical_trades)
# Статистики
p5, p50, p95 = np.percentile(equity_curves[:, -1], [5, 50, 95])
print(f"5th percentile final equity: {p5:.1%}")
print(f"Median final equity: {p50:.1%}")
print(f"95th percentile final equity: {p95:.1%}")
Maximum Adverse Excursion (MAE) симуляція оцінює розподіл максимальної просадки.
def max_drawdown_distribution(equity_curves):
max_dd = np.zeros(len(equity_curves))
for i, curve in enumerate(equity_curves):
running_max = np.maximum.accumulate(1 + curve)
drawdown = (1 + curve) / running_max - 1
max_dd[i] = drawdown.min()
return max_dd
dd_dist = max_drawdown_distribution(equity_curves)
prob_20pct_drawdown = np.mean(dd_dist < -0.20)
print(f"Probability of 20%+ drawdown: {prob_20pct_drawdown:.1%}")
Чому параметрична симуляція точніша?
Параметричні моделі генерують нові дохідності зі статистичного розподілу, що дозволяє моделювати сценарії, відсутні в історії. Ми використовуємо:
Geometric Brownian Motion (GBM):
def gbm_simulation(mu, sigma, S0, T, n_steps, n_sims):
dt = T / n_steps
returns = np.random.normal((mu - 0.5*sigma**2)*dt, sigma*np.sqrt(dt), (n_sims, n_steps))
price_paths = S0 * np.exp(np.cumsum(returns, axis=1))
return price_paths
Student-t distribution (краще для фінансів): Нормальний розподіл underestimates fat tails. Student-t з 3-7 ступенями свободи краще описує реальні return distributions.
from scipy import stats
def student_t_simulation(mu, sigma, df, n_steps, n_sims):
returns = stats.t.rvs(df=df, loc=mu, scale=sigma, size=(n_sims, n_steps))
return np.cumprod(1 + returns, axis=1)
Bootstrap методи: Stationary Bootstrap (випадкові блоки змінної довжини) і Block Bootstrap (фіксовані блоки) зберігають часові залежності.
Оцінка Risk of Ruin
def probability_of_ruin(equity_curves, ruin_threshold=0.5):
"""
Ймовірність втратити >50% капіталу хоча б один раз
"""
min_equity = equity_curves.min(axis=1)
return np.mean(min_equity < (1 - ruin_threshold))
prob_ruin = probability_of_ruin(equity_curves, ruin_threshold=0.5)
print(f"Probability of 50% drawdown (ruin): {prob_ruin:.1%}")
Що входить в розробку системи Monte Carlo?
Ми пропонуємо послугу під ключ: від аналізу вашої стратегії до впровадження автоматичного звіту. Вартість розробки розраховується індивідуально і залежить від обсягу даних, необхідної точності та складності моделей. Економія за рахунок запобігання великим просадкам може бути значною. В середньому проект займає від 2 до 4 тижнів.
| Етап |
Тривалість |
Результат |
| Аналіз даних та стратегії |
1-2 дні |
Звіт про якість даних, первинні розподіли |
| Розробка базової MC рандомізації |
3-5 днів |
Прототип з візуалізацією конуса ймовірності |
| Параметричні моделі та stress testing |
5-10 днів |
Розширена симуляція з GBM, Student-t, сценаріями |
| Автоматизація та дашборд |
3-5 днів |
Регулярний перерахунок MC, алерти при зростанні ризику |
| Документація та навчання |
2-3 дні |
Опис методології, інструкція з оновлення даних |
Ми також включаємо stress testing за сценаріями: криза (збільшення negative skew і fat tails на 2σ), серія з 10 збиткових трейдів поспіль, висока кореляція збитків. Це дозволяє тестувати стратегію в екстремальних умовах.
Monte Carlo також дозволяє підібрати розмір позиції (наприклад, за критерієм Келлі) для максимізації зростання при заданому рівні ризику. Ми реалізуємо симуляцію з різними частками капіталу на угоду та оцінюємо ймовірність розорення для кожної.
Як інтерпретувати результати Monte Carlo?
Стандартні висновки для trader/investor:
- Конус ймовірності (fan chart): p5/p25/p50/p75/p95 шляху капіталу
- Розподіл кінцевої дохідності
- Розподіл максимальної просадки
- Ймовірність різних рівнів drawdown
- Expected time to new equity high
Automated reporting: кожного разу при додаванні нових трейдів — автоматичний перерахунок MC та оновлення звіту. Якщо ймовірність ruin зросла з 3% до 8% — алерт для керуючого.
Наш досвід — понад 10 років у розробці торгових систем та риск-моделей. Ми гарантуємо прозору методологію та чітку документацію. Зв'яжіться з нами, щоб оцінити ваш проект — отримайте консультацію за 2-3 дні. Економія від впровадження Monte Carlo може суттєво знизити ризики великих втрат.
Згідно Monte Carlo method, даний підхід широко застосовується в фінансах для оцінки ризику.
Які проблеми прогнозування часових рядів зустрічаються найчастіше?
Фінансовий директор запитує прогнозування часових рядів продажів на квартал. Аналітик будує SARIMA, досягає MAPE 8.3% на тестовій вибірці — і з гордістю деплоїть. Через два місяці в production метрика падає до 23%. Причина класична: модель навчалася на даних до COVID, тестувалася на стабільному періоді, а production потрапив на промо-акцію та збій поставок. Data leakage + distribution shift = гарні цифри в ноутбуці та непрацюючий прогноз в реальності. Ми стикалися з цим десятки разів. Наш досвід — 5+ років у прогнозуванні часових рядів для рітейлу, фінтеху та IoT, більше 50 завершених проєктів.
Неправильна крос-валідація. Стандартний train_test_split для часових рядів — помилка. Випадкове розбиття створює data leakage: модель бачить «майбутні» значення в навчанні. Правильно — TimeSeriesSplit або walk-forward validation з expanding window.
Множинна сезонність. Погодинні дані споживання електроенергії мають три сезонності: добову (24 год), тижневу (168 год), річну (8760 год). SARIMA справляється лише з однією. Prophet обробляє кілька, але повільно масштабується на тисячі рядів.
Пропуски та аномалії в даних. Пропуск у сенсорних даних — це інформація (датчик відключився), а не просто NaN. Лінійна інтерполяція вбиває цей сигнал. Правильна обробка залежить від природи пропуску.
Cold start при ієрархічному прогнозуванні. Новий SKU в асортименті з 50 000 позицій: історичних даних немає, потрібен прогноз. Стандартні підходи тут не працюють — потрібні cross-learning підходи або feature-based методи.
Які інструменти і коли застосовувати?
Prophet (Meta) — чудовий старт для бізнес-даних із зрозумілою сезонністю та святами. Швидко налаштовується, інтерпретований, вбудована обробка викидів і пропусків. Падає в точності при нерегулярних патернах і не масштабується на десятки тисяч рядів без паралелізації. Prophet (Facebook) — офіційна документація.
Gradient boosting на фічах (LightGBM, XGBoost) — часто недооцінений підхід. Створюєте фічі вручну: лаги (t-1, t-7, t-28), ковзні середні, категоріальні ознаки (день тижня, місяць), екзогенні змінні. Модель навчається на всіх рядах одночасно — вирішує cold start через схожі ряди. MAPE на рітейл-прогнозуванні часто кращий за нейронні мережі при правильній feature engineering.
TFT (Temporal Fusion Transformer) — трансформер, спеціально розроблений для інтерпретованого прогнозування з коваріатами. Вбудовані механізми: variable selection (які ознаки важливі), temporal self-attention (які часові точки впливають на прогноз), квантильні передбачення. Доступний у pytorch-forecasting. Вимагає ~10 000+ записів на ряд для стабільного навчання. Temporal Fusion Transformer — академічна публікація.
PatchTST — трансформер, який ділить часовий ряд на патчі (аналогічно ViT для зображень). Краще захоплює локальні патерни, ніж класичні трансформери. Добре працює для long-horizon forecasting (прогноз на 96–720 кроків). Реалізація в neuralforecast від Nixtla.
N-HiTS, N-BEATS — нейронні архітектури без attention, швидші за TFT, конкурентна точність. N-BEATS виграє на M4/M5 benchmark для задач без коваріат.
| Метод |
Коваріати |
Масштаб (рядів) |
Інтерпретованість |
Складність |
| Prophet |
Так (регресори) |
До 10k |
Висока |
Низька |
| LightGBM + фічі |
Так |
100k+ |
Середня |
Середня |
| TFT |
Так |
1k–100k |
Висока |
Висока |
| PatchTST |
Ні/обмежено |
Будь-який |
Низька |
Середня |
| N-HiTS |
Ні |
Будь-який |
Низька |
Низька |
Як ми розгортаємо TFT в production?
TFT потребує ретельної підготовки даних. Типовий пайплайн через pytorch-forecasting:
training = TimeSeriesDataSet(
data,
time_idx="time_idx",
target="sales",
group_ids=["store", "sku"],
min_encoder_length=max_encoder_length // 2,
max_encoder_length=max_encoder_length, # 120 днів
min_prediction_length=1,
max_prediction_length=max_prediction_length, # 28 днів
static_categoricals=["store_type", "category"],
time_varying_known_reals=["price", "promo_flag"],
time_varying_unknown_reals=["sales"],
target_normalizer=GroupNormalizer(groups=["store", "sku"], transformation="softplus"),
)
Часта помилка: target_normalizer за замовчуванням (StandardScaler) ламає передбачення для рядів з нульовими значеннями (немає продажів у вихідні). GroupNormalizer з transformation="softplus" — правильний вибір для count-даних.
Покрокова інструкція з налаштування TFT
-
Збір та підготовка даних. Обробити пропуски (маркувати NaN, інтерполювати лише якщо це технічний збій), агрегувати до потрібної частоти, сформувати коваріати (свята, промо, ціни).
-
Створення
TimeSeriesDataSet. Вказати group_ids (наприклад, магазин+SKU), часовий індекс, горизонт прогнозу. Налаштувати target_normalizer з урахуванням розподілу таргета.
-
Навчання baseline. Спочатку Prophet або LightGBM — щоб зрозуміти, наскільки складніше завдання.
-
Тренування TFT. Запустити
TemporalFusionTransformer з loss=QuantileLoss(), підібрати learning rate та розміри hidden шарів. Використовувати pytorch_forecasting або neuralforecast.
-
Валідація та інтерпретація. Перевірити walk-forward, проаналізувати variable selection, побудувати attention heatmap.
Кейс: прогноз попиту в рітейлі. Мережа з 120 магазинів, 8000 SKU, горизонт прогнозу 28 днів. Вихідна система: SARIMA окремо для кожного ряду, MAPE 18.4%, повний цикл перенавчання — 6 годин. TFT на PyTorch + pytorch-forecasting: одна модель на всі ряди, MAPE 11.2%, перенавчання — 40 хв на A10G. Додатковий бонус: feature importance через variable selection — з'ясувалося, що day_before_holiday впливає сильніше, ніж сама дата свята. Середня економія бюджету на інференсі для клієнта склала значну суму.
Як правильно оцінювати якість прогнозів?
Не використовуйте RMSE як єдину метрику — вона сильно штрафує за великі помилки на великих значеннях. Наш набір метрик для рітейл-прогнозування:
-
MAPE — інтерпретована, але нестабільна при значеннях близьких до нуля
-
sMAPE — симетрична версія, уникає ділення на маленькі числа
-
MASE (Mean Absolute Scaled Error) — нормалізована відносно наївного сезонного прогнозу, чудово підходить для порівняння між рядами з різними масштабами
-
Quantile loss / Pinball loss — для ймовірнісного прогнозування, оцінка покриття інтервалів
| Метрика |
Коли використовувати |
Недолік |
| MAPE |
Бізнес-звітність, ряд без нулів |
Нестабільна при малих значеннях |
| sMAPE |
Порівняння моделей, нульові значення |
Асиметрична інтерпретація |
| MASE |
Різномаштабні ряди, бенчмарки |
Вимагає сезонного наївного прогнозу |
| Pinball loss |
Ймовірнісні моделі, управління запасами |
Багато метрик для різних квантилів |
Гарантуємо: ми надаємо model card з цими метриками на валідаційній вибірці та результати walk-forward тесту на історії не менше 6 місяців.
Що входить в роботу
- Документація щодо обраної архітектури, обґрунтування вибору гіперпараметрів.
- Відтворюваний пайплайн навчання та інференсу (Docker + CI/CD + Airflow/Prefect).
- Код з коментарями та модульними тестами на ключові компоненти.
- Навчання вашої команди: як перенавчати модель, як інтерпретувати виходи, як деплоїти нові версії.
- Підтримка протягом 3 місяців після здачі: консультації, виправлення багів, доналаштування.
Деталі пайплайну інференсу
Модель деплоїться через FastAPI або Triton Inference Server. Перенавчання запускається за розкладом (наприклад, раз на тиждень) через Airflow — з валідацією drift та автоматичним відкатом при погіршенні метрик.
Процес роботи
Починаємо з EDA: візуалізація, тест ADF на стаціонарність, STL-декомпозиція, аналіз пропусків та викидів. Це 2–3 дні, але часто виявляє системні проблеми даних, які блокують прогнозування.
Потім: baseline (наївний seasonal, Prophet), feature engineering для LGBM, вибір архітектури нейронної мережі якщо потрібно. Walk-forward validation з реалістичним горизонтом. Деплой через API з автоматичним перенавчанням за розкладом через Airflow або Prefect.
Строки орієнтовно: MVP-прогноз на одному типі даних — 3–6 тижнів. Ієрархічна система прогнозування з автоматизацією — 2–5 місяців. Вартість розраховується індивідуально.
Наша команда — сертифіковані ML-інженери (AWS ML Specialty, GCP Professional ML Engineer). За 5 років на ринку реалізували понад 50 проєктів з прогнозування. Зв'яжіться з нами для безкоштовного аналізу ваших даних — ми оцінимо завдання та дамо перші рекомендації за 1–2 дні. Замовте консультацію і переконайтеся, що ваші прогнози працюють в production, а не тільки в ноутбуці.