Движок анализа торговых сигналов

01Обзор проекта

02Инженерная задача

Рыночные данные зашумлены и приходят от внешних сервисов, которые бывают медленными, ограничивают частоту запросов или временно недоступны. Движок должен принимать стабильные решения в этих условиях и оставлять след, объясняющий каждое из них.

• A

  Обработать много инструментов в запланированное окно, не блокируясь на медленных ответах.

• B

  Отделить определение рыночного контекста от оценки конкретного инструмента, чтобы каждый этап можно было анализировать отдельно.

• C

  Отсеивать неполных или противоречивых кандидатов как можно раньше вместо выдачи некачественного результата.

• D

  Сохранять каждый сигнал с контекстом, достаточным для последующей оценки его результата.

03Архитектура решения

Наведите или нажмите на этап.

04Основные компоненты

• 01

  Слой получения данных

  Асинхронные сборщики рыночных временных рядов с контролем частоты запросов, таймаутами и корректной обработкой неполных ответов.

• 02

  Модуль рыночного контекста

  Классифицирует текущее состояние рынка, чтобы последующие фильтры адаптировали своё поведение.

• 03

  Ранжирование кандидатов

  Фильтрует набор инструментов и ранжирует оставшиеся, сохраняя конвейер быстрым и сфокусированным.

• 04

  Цепочка проверок

  Упорядоченные, независимо тестируемые проверки. Кандидат, не прошедший любую из них, отбрасывается с записанной причиной.

• 05

  Хранение сигналов

  SQL-хранилище сигналов, их параметров и жизненного цикла, которое используют отслеживание и отчёты.

• 06

  Планировщик и отчёты

  Запуск по расписанию, отслеживание результатов и диагностические сводки для оператора.

05Технологический стек

07Инженерные решения

1. 01

   Сначала контекст, потом кандидаты

   Однократная оценка состояния рынка в начале упрощает логику по отдельным инструментам и делает обоснование каждого сигнала понятнее.

2. 02

   Отсеивать рано и фиксировать причину

   Каждый шаг проверки может отклонить кандидата с явной причиной. Меньше сигналов с понятным происхождением ценнее, чем много необъяснимых.

3. 03

   Только структурированный результат

   Сигналы — это типизированные объекты, а не текст. Доставка, отслеживание и отчёты работают с одной и той же структурой.

4. 04

   Детерминированное ядро

   Путь принятия решения основан на правилах и воспроизводим для одинаковых входных данных, поэтому регрессии можно обнаружить.

08Надёжность и тестирование

• ✓Таймауты и ограниченные повторы для каждого внешнего запроса.
• ✓Проверка формы входящих данных до начала расчётов.
• ✓Регрессионные проверки при изменении логики фильтров.
• ✓Логи и отчёты, по которым можно объяснить пропущенный или отклонённый инструмент.

09Пример кода

from dataclasses import dataclass, field
from typing import Callable

@dataclass
class Candidate:
    symbol: str
    direction: str          # "LONG" | "SHORT"
    entry: float
    stop_loss: float
    reasons: list[str] = field(default_factory=list)

Check = Callable[[Candidate], str | None]   # returns a rejection reason or None

def has_valid_direction(c: Candidate) -> str | None:
    return None if c.direction in {"LONG", "SHORT"} else "unknown direction"

def stop_on_correct_side(c: Candidate) -> str | None:
    ok = c.stop_loss < c.entry if c.direction == "LONG" else c.stop_loss > c.entry
    return None if ok else "stop loss on wrong side of entry"

CHAIN: list[Check] = [has_valid_direction, stop_on_correct_side]

def run_chain(c: Candidate) -> tuple[bool, str | None]:
    for check in CHAIN:
        if (reason := check(c)) is not None:
            return False, f"{check.__name__}: {reason}"
        c.reasons.append(check.__name__)
    return True, None

Исходный код продукта закрыт. Примеры показывают инженерный подход, а не внутреннюю логику. Больше — в Engineering Lab.

10Возможное развитие

• →Подключаемые источники данных для других площадок и классов активов.
• →Стенд для бэктестов, прогоняющий сохранённые данные через ту же цепочку проверок.
• →Дашборд метрик по этапам, показывающий, где отсеиваются кандидаты.