Торговий робот своїми руками: як завжди, трохи теорії

Про що стаття: архітектура торгового радника

У цій статті — без “сигналів на мільйон” і без обіцянок прибутковості — лише теорія: з чого взагалі збирається торговий радник, як виглядає його архітектура і чому в ній важливі межі відповідальності.

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

Для “мозку”, який інтерпретує дані та формулює висновки, сьогодні часто обирають готові 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 вона навмисно не вставлена.

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