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

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

Советник анализирует рынок и выдаёт рекомендации: где входить, где ставить стоп, где лучше вообще ничего не делать.

Робот делает следующий шаг за вас — и сам открывает/закрывает позиции.

И вот почему “давай сразу робота” — обычно плохая идея. Пока алгоритм не отлажен, риск потери денег максимальный: ошибка в анализе, баг в логике, неверная обработка свечи/ордера — и робот спокойно сделает ровно то, что вы бы не сделали руками.

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

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

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

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

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

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

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

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

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

Данные и API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По материалам itprolab.dev

Источник