← max_tokens

Треугольники на M15–H4: правила фильтруют, LLM решает

Детекция паттернов на чистых правилах захлёбывается ложными срабатываниями: на M15 «треугольник» мерещится алгоритму каждые полчаса. Гонять каждую свечу через модель — другая крайность: дорого и медленно. Рабочая схема оказалась гибридной, и в этом посте — её разбор с цифрами.

Архитектура

Пайплайн из четырёх стадий: поток свечей с Binance WebSocket, детектор-префильтр на правилах, очередь кандидатов и модель-судья, чей вердикт улетает в Telegram. Префильтр намеренно тупой — его задача не быть правым, а быть дешёвым:

def is_candidate(highs, lows, min_touches=3):
    upper = fit_trendline(highs)   # сопротивление
    lower = fit_trendline(lows)    # поддержка
    converging = upper.slope < 0 < lower.slope
    touches = (count_touches(highs, upper)
             + count_touches(lows, lower))
    return converging and touches >= min_touches

Всё, что прошло порог, складывается в очередь с контекстом: свечи трёх таймфреймов, объёмы, расстояние до апекса.

Зачем здесь LLM

Правила дёшево говорят «возможно». Модель дорого говорит «да».

Судья получает кандидата целиком и возвращает структурированный вердикт: валиден ли паттерн, уверенность, причина отказа. То, что правилами описывается страницей условий — «сходящиеся линии, но объём не падает, а это не треугольник» — модель ловит из контекста. На моих данных шум после префильтра режется ещё примерно вдвое.

Экономика

Один вердикт — около 1.5k токенов на вход и 200 на выход. Префильтр пропускает 5–10 кандидатов в час по всем парам, так что счёт за судью — центы в день. Ключевой принцип: платить за инференс только там, где правила объективно слабее.

Дальше — бэктест вердиктов против фактических исходов: считаю не точность модели, а PnL решений, которые она пропустила и зарубила. Об этом — в следующем посте.

<|endoftext|>