Разработка отчётов бэктестов: Sharpe, drawdown, P&L метрики

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка отчётов бэктестов: Sharpe, drawdown, P&L метрики
Средний
~2-3 дня
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Профессиональные отчёты бэктестов: метрики и дашборды

Собрали бэктест, получили финальную доходность 340% — и что дальше? Без детального отчёта это просто число. Мы сталкивались со стратегиями, где win rate превышал 80%, но стратегия сливала 60% капитала за месяц. Потому что не считали max drawdown и не анализировали распределение сделок. Разработка отчётов по бэктестам под ключ — это не просто вывод цифр, а система, которая выявляет скрытые риски, сравнивает гипотезы и обосновывает решения. Наш опыт — более 5 лет в криптотрейдинге и DeFi — позволяет собирать отчёты, которые реально используют в работе. Мы автоматизировали расчёты метрик, чтобы вы не тратили время на ручные эксельки. Многие трейдеры теряют деньги, полагаясь только на P&L — а детальный отчёт с risk-adjusted метриками позволяет избежать этого.

Почему стандартные брокерские отчёты не подходят?

Стандартные брокерские отчёты дают только P&L и simple return. Для алготрейдинга нужны risk-adjusted метрики: Sharpe, Sortino, drawdown duration, profit factor. Без них вы не сможете понять, переживёт ли стратегия рыночный шок или серию убыточных сделок. Мы используем pandas, plotly и собственные dataclass-ы (см. код ниже). Весь пайплайн автоматизирован — от загрузки сделок до HTML-дашборда с интерактивными графиками. Метрика Sharpe широко используется в финансах (Sharpe ratio). Мы гарантируем, что каждый отчёт проходит проверку на консистентность.

Какие подводные камни скрывает типичный бэктест?

Однажды клиент пришёл со стратегией на Binance Futures, показывающей Sharpe 2.3. Мы запустили отчёт с корректным расчётом drawdown — и обнаружили четыре погружения ниже -40%. Причина — стратегия не пережила бы 2-3 неудачных сделок подряд. В отчёте мы добавили секцию "Max drawdown duration" и "Rolling Sharpe". Клиент переработал логику риск-менеджмента — и через месяц Sharpe вырос до 3.8. Наш подход в 3 раза быстрее ручного расчёта в Excel.

Что входит в работу

Мы поставляем полный пакет:

  • Интерактивный HTML-дашборд (Plotly) с equity curve, drawdown, monthly returns heatmap, P&L distribution.
  • Исходные файлы в JSON/CSV для загрузки в ваш риск-менеджмент.
  • Документация: интерпретация каждого графика и метрики.
  • Обучение команды: как обновлять отчёт при изменении стратегии.
  • Поддержка на этапе адаптации — помогаем интегрировать отчёт с вашим API.

Это не разовая работа: мы остаёмся на связи, чтобы доработать метрики под новые требования.

Состав отчёта

  • Дашборды: equity curve, drawdown, monthly returns heatmap, P&L distribution (на plotly или matplotlib).
  • Метрики: Sharpe, Sortino, Calmar, profit factor, win rate, average win/loss, trade duration.
  • JSON/CSV/HTML форматы под ваш риск-менеджмент.
  • Документация: как интерпретировать каждый график.
  • Поддержка после сдачи: мы помогаем адаптировать отчёт под новые стратегии.

Как интерпретировать метрики?

Сравним типичные ошибки. Высокий win rate не спасает, если средний убыток в 3 раза больше средней прибыли. Profit Factor (валовая прибыль / валовый убыток) должен быть > 2. А Sortino Ratio лучше Sharpe — он штрафует только отрицательную волатильность. Наша таблица интерпретации:

Метрика Хорошо Приемлемо Плохо
Sharpe Ratio > 2.0 1.0–2.0 < 1.0
Sortino Ratio > 2.5 1.5–2.5 < 1.5
Max Drawdown < 15% 15–30% > 30%
Profit Factor > 2.0 1.5–2.0 < 1.5
Win Rate > 55% (для трендовых) 45–55% < 45%

Важно: win rate без учёта risk/reward — ловушка. Profit Factor и expectancy важнее.

Сравнение форматов отчёта

Формат Преимущества Недостатки
HTML (Plotly) Интерактивные графики, легко делиться Не подходит для автоматической обработки
JSON Машиночитаем, интеграция с API Требует визуализации отдельно
CSV Универсальный, открывается в Excel Нет графиков, большие файлы

Как мы строим отчёт: пошаговый процесс

  1. Загрузка данных — выгрузка сделок из API или CSV.
  2. Расчёт метрик — вычисление Sharpe, Sortino, drawdown и других показателей.
  3. Генерация графиков — equity curve, drawdown, monthly heatmap, P&L distribution.
  4. Валидация — сверка с исходными данными, проверка консистентности.
  5. Сдача — HTML-дашборд + исходные файлы (JSON/CSV).

Свяжитесь с нами для бесплатной оценки вашего проекта. Закажите разработку отчёта уже сегодня и получите консультацию по оптимизации метрик.

Посмотреть код
from dataclasses import dataclass
from typing import Optional
import pandas as pd
import numpy as np

@dataclass
class BacktestReport:
    # Сводные метрики
    initial_capital: float
    final_capital: float
    total_return_pct: float
    annual_return_pct: float
    
    # Risk-adjusted
    sharpe_ratio: float
    sortino_ratio: float
    calmar_ratio: float
    
    # Drawdown
    max_drawdown_pct: float
    avg_drawdown_pct: float
    max_drawdown_duration_days: int
    
    # Торговля
    total_trades: int
    win_rate: float
    profit_factor: float
    avg_win_pct: float
    avg_loss_pct: float
    best_trade_pct: float
    worst_trade_pct: float
    avg_trade_duration_hours: float
    
    # Комиссии
    total_commission: float
    commission_as_pct_of_pnl: float
    
    # Временные серии
    equity_curve: pd.Series
    monthly_returns: pd.DataFrame
    trade_list: pd.DataFrame
def compute_all_metrics(equity_curve: pd.Series, trades: list[dict]) -> BacktestReport:
    returns = equity_curve.pct_change().dropna()
    annual_factor = 252

    # Базовые
    total_return = (equity_curve.iloc[-1] / equity_curve.iloc[0]) - 1
    days = (equity_curve.index[-1] - equity_curve.index[0]).days
    annual_return = (1 + total_return) ** (365 / max(days, 1)) - 1

    # Sharpe (risk-free rate = 0 для крипто)
    sharpe = (returns.mean() * annual_factor) / (returns.std() * np.sqrt(annual_factor)) if returns.std() > 0 else 0

    # Sortino (только downside volatility)
    downside = returns[returns < 0].std()
    sortino = (returns.mean() * annual_factor) / (downside * np.sqrt(annual_factor)) if downside > 0 else 0

    # Drawdown
    rolling_max = equity_curve.cummax()
    drawdown_series = (equity_curve - rolling_max) / rolling_max
    max_dd = drawdown_series.min()

    # Max drawdown duration
    in_drawdown = drawdown_series < 0
    dd_start = None
    max_duration = 0
    for date, is_dd in in_drawdown.items():
        if is_dd and dd_start is None:
            dd_start = date
        elif not is_dd and dd_start is not None:
            duration = (date - dd_start).days
            max_duration = max(max_duration, duration)
            dd_start = None

    # Calmar
    calmar = annual_return / abs(max_dd) if max_dd != 0 else 0

    # Trade-level
    trades_df = pd.DataFrame(trades)
    if not trades_df.empty:
        winning = trades_df[trades_df['pnl'] > 0]
        losing = trades_df[trades_df['pnl'] < 0]

        win_rate = len(winning) / len(trades_df)
        gross_profit = winning['pnl'].sum()
        gross_loss = abs(losing['pnl'].sum())
        profit_factor = gross_profit / gross_loss if gross_loss > 0 else float('inf')

        avg_win_pct = (winning['pnl'] / winning['entry_value'] * 100).mean() if not winning.empty else 0
        avg_loss_pct = (losing['pnl'] / losing['entry_value'] * 100).mean() if not losing.empty else 0
    else:
        win_rate = profit_factor = avg_win_pct = avg_loss_pct = 0

    return BacktestReport(
        initial_capital=equity_curve.iloc[0],
        final_capital=equity_curve.iloc[-1],
        total_return_pct=total_return * 100,
        annual_return_pct=annual_return * 100,
        sharpe_ratio=round(sharpe, 3),
        sortino_ratio=round(sortino, 3),
        calmar_ratio=round(calmar, 3),
        max_drawdown_pct=max_dd * 100,
        avg_drawdown_pct=drawdown_series[drawdown_series < 0].mean() * 100,
        max_drawdown_duration_days=max_duration,
        total_trades=len(trades),
        win_rate=win_rate,
        profit_factor=profit_factor,
        avg_win_pct=avg_win_pct,
        avg_loss_pct=avg_loss_pct,
        equity_curve=equity_curve,
        trade_list=trades_df,
    )
def compute_monthly_returns(equity_curve: pd.Series) -> pd.DataFrame:
    """Создаём матрицу месячных доходностей для heatmap"""
    monthly = equity_curve.resample('ME').last()
    monthly_returns = monthly.pct_change().dropna()

    # Создаём матрицу год × месяц
    matrix = monthly_returns.groupby([
        monthly_returns.index.year,
        monthly_returns.index.month
    ]).first().unstack()

    matrix.columns = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
                       'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']
    return matrix * 100  # в процентах
def generate_html_report(report: BacktestReport, strategy_name: str) -> str:
    import plotly.graph_objects as go
    from plotly.subplots import make_subplots

    fig = make_subplots(
        rows=3, cols=2,
        subplot_titles=['Equity Curve', 'Drawdown', 'Monthly Returns', 'Trade P&L Distribution', 'Win/Loss', 'Rolling Sharpe'],
    )

    # Equity curve
    fig.add_trace(go.Scatter(x=report.equity_curve.index, y=report.equity_curve.values,
                              name='Portfolio', line=dict(color='#00C853')), row=1, col=1)

    # Drawdown
    rolling_max = report.equity_curve.cummax()
    drawdown = (report.equity_curve - rolling_max) / rolling_max * 100
    fig.add_trace(go.Scatter(x=drawdown.index, y=drawdown.values,
                              fill='tozeroy', name='Drawdown', line=dict(color='#FF5252')), row=1, col=2)

    # P&L distribution
    if not report.trade_list.empty:
        pnl_pct = report.trade_list['pnl'] / report.trade_list['entry_value'] * 100
        fig.add_trace(go.Histogram(x=pnl_pct, name='Trade P&L %', nbinsx=30), row=2, col=1)

    fig.update_layout(
        title=f'Backtest Report: {strategy_name}',
        height=1000,
        showlegend=False,
        template='plotly_dark',
    )

    return fig.to_html(include_plotlyjs='cdn')

Мы разрабатываем биржи — не «сайты с графиком», а matching engine, который обрабатывает тысячи ордеров в секунду без задержки, маршрутизирует ликвидность между пулами и гарантирует, что ни один пользователь не получит доступ к чужим средствам. Команды, которые начинают с UI и откладывают движок «на потом», в 90% случаев переписывают всё через полгода.

Какие проблемы решает правильная архитектура?

Order Book vs AMM: где ломается большинство проектов

Централизованные биржи (CEX) строятся вокруг order book + matching engine. Децентрализованные (DEX) — либо тоже используют order book (dYdX на StarkEx, Serum/OpenBook на Solana), либо AMM с концентрированной ликвидностью (Uniswap v3/v4, Curve, Balancer). Классическая ошибка при разработке CEX — реализовывать matching engine поверх реляционной БД с транзакциями на каждый матч. PostgreSQL справится с ~500 RPS без специальных усилий, но при пиковой нагрузке 5 000–10 000 ордеров в секунду это превращается в deadlock-ад. Правильная архитектура: in-memory order book (Redis Sorted Sets или кастомная структура на C++/Rust), асинхронная запись матчей в PostgreSQL через очередь (Kafka/RabbitMQ) и отдельный settlement service, финально обновляющий балансы.

Для DEX самая болезненная проблема — sandwich атаки и MEV. Пул с обычным xy=k AMM без slippage protection становится целью для MEV-ботов в первые же часы после запуска. Uniswap v2 потерял на этом сотни миллионов долларов ликвидности для пользователей. Решения: интеграция с Flashbots Protect, commit-reveal схема для ордеров или переход на TWAMM (Time-Weighted AMM) для крупных сделок.

Концентрированная ликвидность и impermanent loss

Uniswap v3 ввёл концентрированную ликвидность — LP выбирают ценовой диапазон, в котором предоставляют ликвидность. Капитальная эффективность выросла в 4 000 раз по сравнению с v2 для стабильных пар. Но реализовать этот механизм правильно — нетривиальная задача. Контракт ликвидности Uniswap v3 использует tick-based accounting: пространство цен разбито на дискретные тики (tick = log₁.0001(price)), каждый тик хранит накопленные fee growth и liquidity delta. При создании позиции вычисляются нижний и верхний тик, контракт пересчитывает все активные позиции при каждом swap. Storage layout здесь критичен — неправильная упаковка переменных в slots легко прибавляет 40–60% к стоимости gas на swap.

Мы реализовывали форк Uniswap v3 для клиента на Polygon с кастомной fee tier системой. Первоначальная версия тратила 180k gas на swap через 2 тика. После slot packing переменных в Tick.Info и инлайнинга нескольких internal вызовов — 112k gas. Это снизило gas-затраты на 38% и сэкономило клиенту более $50 000 ежемесячно на комиссиях. Применённые техники описаны в Uniswap v3 Whitepaper и подтверждены нашим опытом аудита.

Что такое matching engine и почему он критичен?

Production-ready matching engine строится по следующей схеме:

  • Order ingestion layer — WebSocket gateway (Go или Rust), принимает ордера, валидирует подпись, проверяет баланс через Redis, ставит в очередь. Latency на этом уровне должна быть <1ms.
  • Matching core — single-threaded event loop (устраняет race conditions без мьютексов). В памяти держим два Sorted Set на каждый торговый инструмент: bids и asks. FIFO matching для limit ордеров, immediate-or-cancel для маркет. Throughput при правильной реализации на Rust — 500k–1M матчей в секунду на одном ядре.
  • Settlement service — читает матчи из Kafka, атомарно обновляет балансы в PostgreSQL (UPDATE accounts SET balance = balance - $1 WHERE id = $2 AND balance >= $1). Optimistic locking через версионирование строк.
  • Withdrawal pipeline — отдельный сервис с cold/hot wallet архитектурой. Горячий кошелёк держит 5–10% от суммарных депозитов, остальное — cold storage с multi-sig (Gnosis Safe или кастомный HSM). Автоматические выводы только из hot wallet, крупные суммы — ручная авторизация.
Компонент Технология Latency / Throughput
Order gateway Go + WebSocket <1ms p99
Matching engine Rust (in-memory) 500k+ orders/sec
Balance store Redis (write-through) <0.5ms
Settlement DB PostgreSQL 14+ ~50k TPS с partitioning
Event streaming Apache Kafka 1M+ events/sec
Blockchain node Geth / Solana validator зависит от чейна

Как мы строим on-chain DEX: смарт-контракты и gas-оптимизация

Для DEX на EVM (Ethereum, Arbitrum, Optimism, Polygon) весь критический путь живёт в Solidity. Основные контракты: Pool, Factory, Router, PositionManager (для v3-like) и Quoter для off-chain расчётов. Типичные ошибки, которые мы видим в аудитах:

Reentrancy через callback. Uniswap v3 использует flash swap с callback (uniswapV3SwapCallback). Если в вашем роутере нет nonReentrant guard и вы не проверяете msg.sender == pool, контракт дренируется через вложенный вызов. Это не гипотетика — несколько форков v3 теряли средства именно так.

Oracle manipulation в AMM. Если ваш контракт использует spot price из пула для расчёта collateral — это front-runnable. Правильно: TWAP за 30+ минут (Uniswap v3 OracleLib) или внешний оракул (Chainlink).

Unbounded loops в liquidity range. Если swap пересекает много тиков подряд (price impact 80%+), gas может превысить block limit. Нужен MAX_TICKS_CROSSED с partial fill и возвратом остатка.

Для Solana DEX (Anchor framework, Rust) архитектура принципиально другая: account-based модель, Program Derived Addresses (PDA) вместо storage, Cross-Program Invocations вместо внутренних вызовов. Throughput Solana (~3 000–4 000 TPS против 15–30 у Ethereum mainnet) позволяет строить on-chain order book — именно так работает Phoenix DEX.

Liquidity bootstrapping и интеграция с агрегаторами

Запустить пул мало — нужно обеспечить ликвидность на старте. Практические механизмы:

  • Liquidity Bootstrapping Pool (LBP) — начальная цена высокая, весовые коэффициенты активов динамически смещаются, создавая давление продаж и равномерное распределение токена. Реализован в Balancer v2.
  • Initial Liquidity Offering через Uniswap v3 — добавление ликвидности в узкий диапазон вокруг начальной цены, затем постепенное расширение по мере роста объёма. Требует active liquidity management или интеграции с Arrakis/Gamma.
  • Интеграция с 1inch, Paraswap, Li.Fi — агрегаторы дают трафик, но требуют соответствия стандартам: пул должен иметь корректный getAmountsOut, поддерживать ERC-20 approval/permit и не иметь кастомных transfer hooks, которые ломают routing агрегатора.

Процесс разработки

Аналитика и проектирование начинаются с выбора архитектурной модели: CEX с кастодиальным хранением, non-custodial DEX или гибрид (off-chain order book + on-chain settlement, как dYdX v3). Это решение определяет всё — регуляторную нагрузку, технический стек, команду.

Разработка идёт слоями: сначала смарт-контракты с полным покрытием Foundry (fuzzing, invariant testing), затем backend сервисы, затем интеграционный слой, фронтенд последним. Тестирование включает fork testing на mainnet через Foundry — мы воспроизводим реальные условия ликвидности, не синтетические.

Аудит обязателен перед деплоем на mainnet. Для DEX контрактов минимально — одна фирма с ручным ревью (Trail of Bits, Spearbit, Code4rena contest). Для CEX custody — аудит процессов хранения ключей. Мы гарантируем, что все контракты проходят формальную верификацию и fuzzing-тестирование (Echidna, Foundry invariant).

Что входит в работу (deliverables)

По завершении проекта вы получаете:

  • Исходный код смарт-контрактов и backend-сервисов под вашу лицензию
  • Полную техническую документацию (архитектурные схемы, API-спецификации, инструкции по деплою)
  • Доступы к репозиторию и CI/CD pipeline
  • Обучение вашей команды работе с кодом (2–3 сессии)
  • Гарантию на найденные в процессе эксплуатации баги до 6 месяцев
  • Сертификат прохождения стороннего аудита безопасности

Ориентиры по срокам

  • DEX (AMM, xy=k) — от 3 до 5 месяцев: контракты + backend + UI
  • DEX с концентрированной ликвидностью (v3-like) — от 6 до 10 месяцев
  • CEX (matching engine + custody + торговый UI) — от 8 до 14 месяцев
  • Интеграция с существующим протоколом — от 4 до 8 недель

Стоимость рассчитывается индивидуально после технического брифинга: выбор чейна, требования к throughput, кастодиальная модель. Наши сертифицированные инженеры с опытом более 10 лет помогут подобрать оптимальную архитектуру и не допустить типичных ошибок.

Типичные грабли при запуске

  • Забывают про price oracle в AMM. Spot price манипулируется flash loan’ом за одну транзакцию. Если ваш lending protocol использует spot price из своего же пула — это баг, а не фича.
  • Горячий кошелёк без лимитов. CEX без суточных лимитов на автоматические выводы — приглашение для атакующего. Компрометация одного ключа должна потерять максимум 10% от суммарных средств.
  • Отсутствие circuit breaker. Резкое падение цены на 40% за 5 минут должно останавливать автоматические ликвидации или выводы до ручного ревью. Без этого cascading liquidation spiral уничтожает весь TVL.
  • Неправильный decimal handling. USDC использует 6 decimals, WBTC — 8, большинство токенов — 18. Смешивание без нормализации даёт либо потерю точности, либо overflow. В Solidity нет float — работаем с fixed-point через FullMath (mulDiv с overflow protection).

Хотите избежать этих проблем? Свяжитесь с нами для консультации — мы подберём архитектуру под ваш проект и назовём точные сроки. Закажите разработку биржи с гарантией качества и последующей поддержкой.