Торговый робот своими руками: как обычно, немного теории

О чём статья: архитектура торгового советника

В этой статье — без “сигналов на миллион” и без обещаний доходности — только теория: из чего вообще собирается торговый советник, как выглядит его архитектура и почему в ней важны границы ответственности.

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

Для “мозга”, который интерпретирует данные и формулирует выводы, сегодня часто выбирают готовые LLM-сервисы: ChatGPT, Gemini, Grok. При желании их можно дообучать или заменить своей моделью, но для архитектуры это вторично.

Нюанс остаётся тем же: нейросеть не читает ваши мысли. Ей нужен промпт — внятный, формализованный и повторяемый.

Промпт — это текстовая инструкция (и контекст), которую вы передаёте модели: что за данные перед вами, что именно нужно сделать и в каком формате вернуть ответ.

И ещё нужны данные, с которыми мы будем работать.

Здесь дальше главный вопрос: что именно класть в промпт (свечи, индикаторы, стакан, сделки, контекст риска) и в каком виде.

Данные и API

Про промпт поговорим позже, а сейчас — о данных.

Начальный уровень выглядит просто:

1. Получить данные о курсах (котировки).
2. Скомпоновать их с контекстом запроса.
3. Передать это в промпт нейросети — через тот самый API.

Почти все биржи дают доступ к котировкам программно. И да — тоже через API.

Давайте на минуту отвлечёмся и уясним, что мы вообще называем API, раз слово уже встречается несколько раз и дальше будет встречаться постоянно.

API (Application Programming Interface) — это интерфейс взаимодействия между программами.

На практике это “правила игры”:

• какие запросы можно сделать (например: получить свечи, получить ордербук);
• в каком формате передавать данные (часто JSON);
• как выглядит ответ (структура полей, ошибки, лимиты, авторизация).

Проще говоря: API позволяет вам пользоваться возможностями биржи (или нейросети) как набором функций, не влезая внутрь реализации.

Пользовательский слой: как показывать результат

Итак, на этом этапе у нас уже есть два базовых компонента:

• данные (мы берём их с биржи);
• аналитик (нейросеть, которой мы скармливаем данные и получаем вывод/сигнал).

Но приложение, которое само в себе получает данные и само их анализирует, бесполезно до тех пор, пока результат не увидит человек.

Значит нужен третий компонент — интерфейс.

Самый простой и универсальный вариант — веб-интерфейс: график, последние сигналы, объяснение “почему так”, настройки риска.

Как опция — уведомления в мессенджеры (например, Telegram): краткий сигнал + ссылка на подробности в вебе.

Контекст поверх цены: новости

Для базовой версии этого достаточно, но если хочется глубже — можно добавить ещё один слой контекста: новости.

Идея простая: мы собираем релевантные новостные статьи и добавляем их в промпт. Обычно — не “сырьём”, а в виде коротких саммари (чтобы не забивать контекст и не улетать в токены).

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

Как увязать всё вместе

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

На практике почти всегда получается два режима.

Анализ по запросу

Пользователь нажал кнопку (или дёрнул endpoint) → мы подтянули свежие котировки → собрали промпт → получили ответ модели → показали сигнал.

• Плюсы: экономно по токенам/ресурсам, проще отлаживать.
• Минусы: вы гарантированно пропускаете часть событий между запросами — вместе с ними пропускаются и точки входа.

Регулярный анализ по расписанию

Пользователь задаёт периодичность (например, раз в 5 минут/час/день) → система сама гоняет конвейер и пушит результат.

• Плюсы: сигналы приходят регулярно, можно держать “пульс рынка”, легче собирать статистику.
• Минусы: дороже (токены/инфраструктура), нужны лимиты и защита от “самострела” (rate limit, ретраи, дедупликация сигналов), плюс обязательны мониторинг и логирование — иначе вы не поймёте, почему в 03:17 всё внезапно замолчало.

В любом из режимов набор базовых компонентов одинаковый:

• web-сервер (интерфейс и API для пользователя);
• модуль биржевых данных (котировки, свечи, при необходимости — стакан/сделки);
• модуль LLM (сбор промпта → вызов модели → парсинг ответа);
• хранилище (настройки пользователя, история сигналов, кэш котировок, результаты анализа).

И нужен один “клей”, который всё это связывает: сущность уровня приложения — назовём её core/service — которая управляет зависимостями, жизненным циклом и сценариями (по запросу или по расписанию).

На перспективу почти всегда выгодно заложить плагинный подход:

• плагины для источников котировок (добавили новую биржу — не переписываем остальное);
• плагины для LLM-провайдеров (появилась новая модель/поменялись тарифы — меняем адаптер, а не архитектуру).

Примечание: здесь планируется схема архитектуры (диаграмма) — в этой версии HTML она намеренно не вставлена.

Дальше можно уже приземляться на реализацию: какие интерфейсы у модулей, какие структуры данных, и где проходит граница между “советником” и “торговым роботом”.