Розробка трендових ліній: де ламається автоматика
Автоматичне побудова ліній здається простим завданням: дві точки задають промінь, далі — лише продовження. На реальних даних ламається не геометрія, а підготовка серії.
Перший клас відмов — розсинхронізація котирувань. Скрипт рахує за локальною історією, а трейдер дивиться на потік брокера: бари закриваються в різних часових поясах, тикові дані підтягуються заднім числом, у серії залишаються пропуски вихідних і технічних перерв.
Промінь, порахований за такою історією, з'їжджає на кілька пунктів, і сигнал перестає збігатися з графіком.
Другий — перемальовування лінії. Поки останній бар не закритий, екстремум перераховується на кожному тику, і промінь «дихає»: трейдер бачить пробій, якого за хвилину вже немає.
Без правила «рахувати лише закриті бари» автоматика й ручне розмічання графіка в TradingView живуть у двох різних реальностях, і довіра до системи падає після другого такого випадку.
Третій — різна логіка на різних інструментах. Поріг чутливості, мінімальна довжина променя й допустимий нахил добираються під волатильність конкретного активу: ті самі константи на ф'ючерсі чи на криптопарі дають або сотні перетинних ліній, або жодної.
Розробка трендових ліній тому починається з моделі даних і правил перевірки серії, а не з малювання. Розбираємо, як це закривається в коді.
Ефект автоматизації: менше хибних сигналів і ручної роботи
Ручна робота з лініями зникає майже повністю: правила побудови задаються один раз, далі система сама підтягує екстремуми, перераховує кути нахилу після розриву й продовжує рівні.
Аналітик більше не перемальовує розмітку при зміні періоду графіка — на його частку залишається перевірка гіпотез і налаштування порогів чутливості.
Клас хибних спрацювань скорочується завдяки умовам підтвердження. Пробій без закріплення за рівнем і без зростання активності в стакані не вважається сигналом, тому деренчання біля межі та подвійні дотики в шумі відсікаються до того, як потраплять в оповіщення. Залишаються події, які справді змінюють структуру руху.
Швидкість побудови ліній вимірюється секундами, а перезбирання після збою — хвилинами: стан розмітки зберігається окремо від ринкових даних і відновлюється із журналу.
Раніше такий збій означав заново пройдені вручну години, тепер — автоматичне звіряння й продовження роботи з тієї самої точки.
Стійкість розмітки тримається на єдиних правилах для всіх інструментів і періодів. Лінія, побудована на одному екрані, збігається з тією самою лінією у звіті та в оповіщенні, розбіжностей між версіями розрахунку немає.
Це прибирає суперечки про те, «правильна» чи розмітка, і знижує витрати праці аналітика до контролю винятків.
Режими розрахунку трендових ліній: порівняння підходів
Трендова лінія в автоматичній системі — не малюнок поверх графіка, а результат обчислення за масивом точок.
Різні режими дають різне положення однієї й тієї самої лінії на одних даних: те, що аналітик побудує «на око» за секунду, алгоритм має відтворювати однаково за кожного перерахунку. Тому вибір режиму — частина логіки розрахунку, а не налаштування відображення.
| Режим розрахунку | Коли підходить | Обмеження |
|---|---|---|
| Лінія за екстремумами | Розмітка за значущими піками й западинами: лінія торкається двох-трьох підтверджених точок | Чутливий до вибору точок і викидів — один зайвий екстремум змінює кут нахилу, а на рваних ділянках лінія перебудовується занадто часто |
| Лінія за регресією | Щільні однорідні ряди, де потрібен стійкий нахил на довгому інтервалі | Усереднює всю вибірку: зміна тренду розмивається, лінія запізнюється й відходить від фактичної межі руху |
| Згладжування розмітки | Дані з шумом, пропусками й нерегулярними інтервалами, коли важлива стабільність картинки | Вікно згладжування саме вносить затримку: коротке дає смикання, довге реагує на рух, який уже закінчився |
| Комбінований | Перехідні ділянки: екстремуми задають межі, регресія — нахил між ними | Складніше налагоджувати: помилка одного шару маскується іншим, потрібна явна метрика якості перебудови |
Режим добирається під характер інструмента й горизонт, на якому лінія має залишатися валідною.
Перед запуском проганяємо кожен варіант на історичних даних і дивимося, як часто лінія перебудовується й наскільки розходяться результати за повторного розрахунку — так видно, де метод починає брехати.
Порядок упровадження: від аудиту даних до передачі системи
Автоматичне розмічання трендових ліній ламається не на коді, а на даних і визначеннях.
Поки не зафіксовано, що вважати дотиком, який допуск на прокол і як обробляти розриви котирувань, будь-яка реалізація дає лінії, які на історії виглядають переконливо, а на нових даних перебудовуються щодня. Тому порядок робіт жорсткий: спочатку дані й правила, потім розрахунок, далі перевірка й передача.
- Аудит історичних даних. Перевіряємо повноту рядів: пропуски, дублі, розриви на стику сесій, зміну режимів торгів. На виході — звіт про якість і правила передобробки, без яких розрахунок нестійкий.
- Формалізація правил розмітки. Фіксуємо, що вважати значущим екстремумом, мінімальну довжину лінії, допустимий прокол і поведінку при пробої: лінія обривається, продовжується чи будується заново.
- Схема розрахунку лінії. Описуємо алгоритм: вікно аналізу, порядок пошуку опорних точок, перевірку на перетин із тілами свічок, чутливість до таймфрейму. Це документ, за яким розрахунок можна відтворити й оспорити.
- Упровадження системи розмітки. Збираємо розрахунок, сховище ліній і робоче місце аналітика; параметри виносимо в конфігурацію, щоб змінювати чутливість без переписування коду.
- Перевірка на історії. Проганяємо систему на різних режимах ринку й звіряємо з ручною розміткою аналітика: рахуємо частку збіглих ліній і розбираємо розходження — зазвичай вони вказують на недомовлене правило, а не на помилку в коді.
- Передача системи замовнику. Віддаємо конфігурації, схему розрахунку, регламент оновлення даних та інструкцію з правки параметрів, навчаємо команду.
- Супровід. Після запуску стежимо за розходженням ручної й автоматичної розмітки та доналаштовуємо параметри при зміні волатильності.
Конфігурації, схеми й регламенти: що передаємо на руки
Код — лише половина системи. Трендова лінія будується за десятками параметрів: вікно згладжування, мінімальна кількість дотиків, поріг підтвердження пробою, набір таймфреймів.
Якщо вони зашиті у вихідні коди, кожна правка тягне перезбирання й реліз, а розібратися, чому лінія перебудувалася вночі, не виходить. Тому на руки йде не репозиторій, а комплект, за яким систему можна вести без нас.
- Файли конфігурації — параметри розрахунку ліній, список інструментів і таймфреймів, розклад перерахунку, підключення до джерел котирувань. Змінюються без правки коду й перезбирання.
- Схема потоків даних — від приймання котирувань до публікації лінії: де нормалізація, де відсів аномальних свічок, де запис у сховище і хто читає результат.
- Правила доступу — ролі аналітика, інженера й чергового: що допустимо правити в робочому контурі, а що лише через перевірку й підтвердження другим фахівцем.
- Інструкції для команди — як додати новий інструмент, перерахувати історію, відтворити побудову лінії на конкретну дату й звірити результат з еталоном.
- Регламент експлуатації — обов'язкові перевірки за розкладом, пороги оповіщень, порядок відкату на попередню версію розрахунку.
- Карта залежностей — зовнішні джерела й сервіси, поведінка системи за їх недоступності, явні точки відмови й обхідні сценарії.
Комплект оновлюється разом із системою: нова команда входить у проєкт за документами, а не за пам'яттю попередніх розробників.
Кейс: скоротили ручну роботу над розміткою втричі
Як було
Розмітку трендових ліній аналітики вели вручну: за кожним інструментом вивантажували свічки, малювали лінії дотиків і підтверджували пробої очима.
На корпус із кількох тисяч графіків ішов робочий тиждень, а вузьким місцем виявилося не саме малювання, а перезбирання розмітки: будь-яка правка правил — мінімальна довжина лінії, допуск на пробій, глибина історії — обнуляла результат, і корпус розмічали заново.
Що змінили
Зібрали автоматичну систему: опорні точки шукаються за локальними екстремумами, близькі дотики кластеризуються, а правила валідації винесені в конфігурацію — їх змінюють без правки коду.
Розмітка стала версіонованим набором: до кожного графіка пишеться версія правил, тому після зміни логіки перезбирається весь корпус, а не один інструмент.
Звіряння вели на еталонній вибірці: дані брали з CoinGecko, поруч тримали вручну розмічений контрольний набір — він же слугує перевіркою за кожної правки правил. Аналітики працюють у панелі: підтверджують або відхиляють лінію, і рішення повертається у вибірку.
Підсумок за метриками: час на розмітку корпусу скоротився втричі, частка хибних спрацювань упала з 18% до 6%, спірні випадки йдуть на ручну перевірку окремою чергою. Перезбирання після правки правил займає години замість днів, відкат до попередньої версії розмітки — одна команда.
Що робити, якщо розмітка вже ведеться вручну?
Ручна розмітка — це не хаос, а неформалізована логіка, яку аналітик тримає в голові. Перший крок переходу — витягнути її назовні: які екстремуми беремо за опорні, скільки дотиків вважаємо достатніми, який допуск на прокол ціни, за якої умови лінія вважається пробитою.
На практиці шість-десять таких правил покривають більшість рішень, а решта — рідкісні випадки, які описуються довідником винятків.
Переносимо не «як вийде», а зі збереженням накопиченого: наявні лінії імпортуються в систему як еталонний набір, історія розмітки не обривається на даті запуску й залишається доступною для порівняння та відкатів.
Далі автоматика запускається в тіньовому режимі поруч із ручною роботою — вона будує лінії на тих самих даних, але нічого не публікує.
Поетапність тут принципова: спочатку один інструмент або один масштаб графіка, потім розширення на решту, коли розходження розібрані. Ручний режим залишається доступним — ним перевизначають лінію, яку алгоритм не побачив, і це саме перевизначення стає правилом.
Збіг результатів перевіряємо вимірювано: частка ліній, побудованих так само, як в аналітика, середнє відхилення за положенням і нахилом, час від формування точки до появи лінії. Розходження — не привід зупиняти перехід, а матеріал для калібрування допусків.
Підсумок — перехід без паузи в роботі, ціла історія розмітки й зрозумілий критерій, за яким видно, що автоматика не гірша за ручну роботу.
Технічні сумніви: обмеження й сумісність
Якість ліній упирається в якість вхідного ряду: пропущені свічки, зсув міток часу між джерелами й різна глибина історії дають розриви там, де тренд насправді неперервний.
Тому перед розрахунком ряд нормалізується — інтервали приводяться до єдиної сітки, пропуски закриваються за узгодженим правилом, а ділянки, де даних достовірно немає, виключаються з малювання.
На різких рухах лінія може перебудуватися на останній свічці: екстремум ще не сформований, і будь-який метод, що чіпляється за поточний максимум, дає перемальовування.
Це обмеження закриваємо явно — або фіксуємо лінію за закриттям, або позначаємо її попередньою, щоб у торговій логіці вона не брала участі до підтвердження.
Що буде, якщо джерело почне віддавати неповні свічки?
Ставимо детектори аномалій: розходження обсягу з історичним профілем, нульові діапазони, дірки в часовому ряді. При спрацюванні ділянка позначається недостовірною, лінія за нею не будується, у моніторинг іде повідомлення. Хибний пробій не перетворюється на сигнал.
Як система вбудовується в уже працюючий контур?
Через штатний обмін: розрахунковий шар віддається окремою службою з документованим інтерфейсом, схемами потоків і форматами повідомлень. Ваші термінали й сховища залишаються на місці — змінюється лише джерело ліній, повернення до попереднього розрахунку займає хвилини.
Що з підтримкою після запуску?
Перші тижні ведемо спостереження на реальному потоці, звіряємо розрахунок з еталонною вибіркою. Далі — планові перевірки цілісності даних та оновлення правил нормалізації, коли змінюється розклад торгів.
Обговоримо вашу задачу й повернемося з оцінкою та планом
Щоб повернутися з оцінкою, а не з діапазоном «від і до», нам потрібен мінімум вихідних даних. Вони займають у вас один вечір, зате знімають тиждень уточнювальних питань — план робіт збирається за фактом, а не за здогадками.
- Опис процесу — як трендові лінії будуються зараз: вручну, скриптами чи стороннім сервісом, хто і як часто це робить.
- Приклади даних — 2–3 вивантаження в тому вигляді, у якому вони надходять: свічки, угоди, котирування, мітки часу й часові пояси джерел.
- Поточні інструменти — мова, бібліотеки, шлюзи до біржових даних, сховище; що вже працює і що доводиться дописувати руками.
- Правила побудови — які методи проведення ліній використовуєте, скільки ліній на інструмент, як обробляєте перетини, пробої та розриви в історії.
- Очікуваний результат — що має з'являтися на виході: графік, сигнал, повідомлення чи вивантаження у звіт, і з якою періодичністю.
- Обмеження — доступи, регламенти щодо зберігання даних, вимоги до затримки й до збереженості історичних рядів.
Далі ми розбираємо матеріали, добираємо склад команди під задачу й надсилаємо план: етапи, що перевіряємо на кожному, який результат вважається прийнятим і коли запускається перша робоча версія.
Обговоримо задачу — опишіть процес, додайте приклад даних і поточний інструментарій, повернемося з оцінкою та планом.
