Розробка рекомендаційної системи криптовалют: де ламається сигнал
Правило, знайдене на історичних даних, працює лише в тому режимі ринку, де його виявили.
Поки волатильність ринку низька, а ліквідність розподілена передбачувано, ваги впевнено розділяють активи; зі зміною режиму — різким рухом або перетіканням обсягу між майданчиками — та сама логіка починає видавати хибні сигнали, причому тим частіше, чим упевненіше вона виглядала на минулому відрізку.
Розрив проявляється в перші дні після зламу тренду, коли модель ще не встигла набрати новий контекст.
Друге джерело помилок — затримка даних. Ціна, обсяги та дані з мережі надходять асинхронно й з різною частотою, а частина джерел віддає зріз із запізненням в один-два інтервали.
Якщо збирання та розрахунок балльної оцінки не узгоджені в часі, підказка формується на застарілій картині: аналітик бачить рекомендацію, яку ринок уже не підтверджує.
Якість історичних даних погіршує картину. Пропуски, різні часові пояси в джерел, ретроактивні правки свічок і вибірка, що вижила, з якої випали делістинговані інструменти, роблять набір «зручним»: модель жодного разу не бачила, як поводиться ринок, коли половина активів зникає. На такому наборі будь-яка конфігурація виглядає надійнішою, ніж виявиться в роботі.
Для аналітичного контуру це обертається втратою довіри до підказок: рішення ухвалюються, а зворотний зв'язок щодо них не збирається, і оцінити, де саме помилилася система, уже неможливо.
Розбираємо, як це закривається — від стійкості до зміни режиму та контролю свіжості даних до перевірки якості історії перед тим, як на ній щось будувати.
Що змінюється після впровадження: точність сигналів і швидкість відгуку
До впровадження оцінки розраховувалися пакетно: ринок уже пішов, а видача наздоганяла його із затримкою. Багатофакторний скоринг переводить перерахунок на подієву модель — вага кожного фактора змінюється разом із ціною, обсягом і ліквідністю, а не за розкладом.
Точність і частка хибних спрацювань
Скоринг тримає кілька незалежних факторів і гасить сигнал, якщо вони розходяться між собою. Поріг підтвердження налаштовується окремо за класом активу: частка хибних спрацювань знижується приблизно вдвічі без втрати кількості прийнятих сигналів.
Дані про глибину ринку підтягуються з кількох джерел, включно з CoinGecko, тому видача не просідає у разі збою одного з них.
Швидкість перерахунку під час руху ринку
Перерахунок запускається подією, а не таймером: оцінка оновлюється в межах секунд після сплеску волатильності.
Рекомендація, яка застаріла за час розрахунку, позначається як неактуальна і не доходить до споживача — зникає цілий клас відмов, коли рішення ухвалювалося за вчорашнім знімком ринку.
Стійкість на піках навантаження
Черга перерахунку відокремлена від віддачі результатів: сплеск запитів не гальмує переоцінку, а переоцінка не блокує інтерфейс. На піках час відгуку залишається рівним, а пропускна здатність зростає додаванням обробників без переписування логіки скорингу.
Порівняння режимів оцінювання активів: потоковий, пакетний, гібридний
Режим розрахунку визначає, як швидко рекомендація відображає зміну ринку і скільки інфраструктури вона споживає.
Вибір не бінарний: потокова обробка, пакетний перерахунок і гібридний режим закривають різні завдання, і на одній вітрині вони часто сусідять — нові активи розраховуються безперервно, а історичні профілі перераховуються вночі.
Критерій вибору — припустима затримка видачі та профіль навантаження. Якщо сигнал потрібен у момент входу в позицію, добовий перерахунок не підходить: до вечора ваги факторів розходяться з ринком.
Якщо рекомендації оновлюються для довгострокового портфеля, безперервна обробка додає навантаження без виграшу в точності.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пакетний перерахунок | Довгострокові портфелі, оновлення раз на добу або рідше, важкі моделі | Затримка видачі — години; на різкому русі ринку ваги факторів застарівають |
| Потокова обробка | Сигнали в момент угоди, реакція на волатильність за секунди | Постійне навантаження на піках, потрібен запас потужності та контроль черг подій |
| Гібридний режим | Змішані сценарії: часті поправки поверх рідкого повного перерахунку | Складніший у супроводі — дві гілки розрахунку та правила їх узгодження |
На практиці частіше обирають гібридний режим: важкі перерахунки йдуть пакетно, а легкі поправки — потоком. Це згладжує навантаження на піках і тримає затримку видачі в межах, які задає сам продукт, а не інфраструктура.
Етапи впровадження: від розбору даних до передачі в експлуатацію
Перш ніж розраховувати оцінки, ми розбираємо дані: біржові угоди та стакан, ончейн-метрики, новинні й соціальні сигнали — у кожного джерела своя частота оновлення і своя затримка.
Система, побудована поверх брудного потоку, відтворює його перекоси, тому перший етап — інвентаризація та замір якості, а не навчання моделі.
- Розбір джерел даних. Складаємо перелік потоків, для кожного фіксуємо частоту, затримку, глибину історії та спосіб доставки. Окремо рахуємо частку пропусків, дублів і аномальних значень — за ними видно, які джерела доведеться чистити, а які замінювати.
- Схема розрахунку. Визначаємо, з яких факторів складається підсумковий бал активу: динаміка ціни та обсягу, ліквідність, волатильність, ончейн-активність, новинний фон. Для кожного задаємо вікно, спосіб нормування та правила відсікання викидів, щоб різні шкали стали порівнюваними.
- Налаштування ваг. Внесок факторів калібруємо на історичних даних і обмежуємо зверху, щоб один шумний сигнал не перетягував рекомендацію на себе. Ваги виносимо в конфігурацію, а не в код — їх правлять без перезбирання та релізу.
- Перевірка на історичних зрізах. Проганяємо схему на послідовних періодах, навчаючись лише на минулому, — так виключаємо підглядання в майбутнє. Дивимося не лише на дохідність, а й на стійкість ранжування при зсуві періоду та при вимкненні окремого фактора.
- Приймання та передача в експлуатацію. Розгортаємо розрахунок, налаштовуємо моніторинг якості вхідних даних і дрейфу оцінок, описуємо регламент перегляду ваг і порядок відкату на попередню версію схеми.
Після передачі команда замовника бачить, чому актив отримав саме такий бал: кожен фактор і його внесок залишаються спостережуваними, а не розчиняються в «чорному ящику». Це робить систему підтримуваною силами власних інженерів.
Що передаємо на руки: конфігурації, схеми, регламенти, документація
Проєкт закривається не демонстрацією, а набором артефактів, за якими систему розрахунку рекомендацій можна експлуатувати й розвивати без нас.
Усе перелічене передається у ваш репозиторій із правами на зміну — не звіт, а робочі одиниці: конфігурація, схеми, регламенти, документація.
- Файли конфігурації розрахунку: ваги факторів, пороги спрацювання сигналів, вікна усереднення, правила відсікання низьколіквідних інструментів — з коментарями, звідки взято кожне значення і за якою межею якість оцінки падає.
- Схеми потоків даних: від джерел котирувань і подій у мережі до вітрини рекомендацій, з точками контролю, затримками на кожній ділянці та місцем, де розраховується кожна метрика.
- Політики доступу: ролі на читання та на зміну ваг, розділення прав до історичних даних і до конфігурації робочого контуру, журнал усіх правок з автором і часом.
- Регламент оновлення ознак: частота перерахунку, порядок додавання нового фактора, обов'язкова перевірка на історичних даних перед викочуванням і процедура відкату конфігурації до попередньої.
- Документація з розрахунку: формули агрегації багатофакторної оцінки, припущення при пропусках у даних, поведінка системи при затримці або втраті джерела.
- Моніторинг: набір контрольних метрик якості видач, пороги деградації, порядок дій чергового інженера та шаблони оповіщень.
- Інструкція з розгортання та відновлення: збирання середовища з нуля, міграції сховища, контрольна точка, з якої система піднімається після збою.
З практики: перезбирання оцінки активів для контуру біржової аналітики
Розбираємо кейс аналітичного контуру біржі: одиночний сигнал потрібно було замінити багатофакторною оцінкою активів, щоб підказки не ламалися на волатильних ділянках. Робота йшла ітераціями — спочатку зняли метрики «до», потім збирали фактори та перебудовували сам розрахунок.
Що не працювало
Рекомендації будувалися на одній ознаці — динаміці ціни за останні години. На спокійному ринку частка помилкових підказок трималася близько 34%, а на різких рухах видача фактично переверталася: актив потрапляв до списку купівлі вже на розвороті.
Повний перерахунок набору займав понад 40 хвилин, тому на момент публікації частина сигналів встигала застаріти, а стійкість розрахунку в пікові години трималася лише завдяки ручному втручанню аналітиків.
Що змінили і що отримали
Зібрали багатофакторну оцінку: патерни ціни, глибину стакана заявок, ліквідність пари, волатильність і кореляції всередині кошика. У кожного фактора з'явилася вага, в підсумкового бала — поріг упевненості: нижче нього підказка не публікується, а переходить у режим спостереження.
Розрахунок перенесли в колонкове сховище ClickHouse, перерахунок зробили інкрементальним — лише за зміненими інструментами.
Розбір помилок вбудували в сам цикл: відхилену підказку позначають причиною — застарілий сигнал, тонка ліквідність, конфлікт факторів, — і ваги переглядають за накопиченою статистикою.
Підсумок за метриками: частка помилкових підказок упала з 34% до 11%, повний перерахунок скоротився з 40 до 3 хвилин, частка рекомендацій, скасованих протягом години після публікації, — з 27% до 6%.
Відмов розрахунку під навантаженням більше немає: черга деградує поступово, віддаючи пріоритет великим парам.
Чим потокова оцінка активів відрізняється від пакетної
Різниця в тому, коли розраховується скор. Пакетна оцінка перераховує весь список активів за розкладом, потокова оновлює оцінку за кожною подією — щойно надійшла угода або змінився стакан. Дані ті самі, різниться момент обчислення та вимоги до контуру.
За затримкою та навантаженням це два різні профілі. Потоковий контур тримає вікно ознак у пам'яті та рахує приростами: реакція — секунди, але навантаження постійне, його планують із запасом на піки ринку.
Пакетний дає короткі сплески: у простої ресурси вільні, зате рішення надходить із затримкою вікна перерахунку.
Налагодження відрізняється сильніше. Пакетний розрахунок детермінований: одне вікно даних дає один результат, збій відтворюється повторним прогоном.
Потоковий залежить від порядку й часу надходження подій, тому потрібні дедуплікація, ідемпотентний запис і збереження вхідного потоку — інакше інцидент не розібрати.
Вибір режиму впирається в потрібний час реакції та в те, як швидко змінюються самі ознаки. За multi-factor scoring з десятками факторів основним залишають пакетний перерахунок, а потоковим закривають ознаки із секундною реакцією: сплески обсягу, різкі рухи ціни.
Якщо контур уже розгорнуто, переписувати його не потрібно: пакетний шар залишається джерелом істини, а потоковий ставиться поверх як прискорювальний — читає той самий потік даних від джерела на кшталт CoinGecko і пише до того самого сховища оцінок.
Режим перемикається конфігурацією, тож спочатку розгортаємо гібрид і звіряємо розходження на історичних вікнах.
Технічні сумніви: дані, затримки, стійкість моделі
Рекомендації спираються на потік котирувань, глибину ринку та історію угод — дані надходять нерівномірно, з різною затримкою та пропусками.
Нижче — відповіді на сумніви, які зазвичай виникають до старту: затримки джерел, розриви ліквідності, перенавчання моделі, обсяг історії та стикування з вашою платформою.
Що станеться при затримці або обриві джерела даних?
Котирування надходять від кількох незалежних постачальників і звіряються між собою. Якщо один відстає або віддає викид, система бере підтверджений зріз і позначає оцінку як неповну, а при розриві ліквідності зупиняє видачу замість розрахунку за застарілою ціною.
Як ви захищаєтеся від перенавчання моделі?
Навчання й перевірка розділені в часі, між вікнами залишено зазор — модель не може підглянути майбутні дані. Якість рахуємо за кожним періодом окремо, тому падіння на новому відрізку видно відразу, а не після запуску.
Скільки історичних зрізів потрібно і як вони зберігаються?
Потрібні періоди і зростання, і падіння, включно з низькою ліквідністю. Зберігаємо зрізи знімками з фіксованим кроком: перерахунок ознак не ламається, якщо постачальник заднім числом поправив історію.
Що з якістю даних?
Пропуски, дублі та дроблення угод відсікаємо на вході за явними правилами. Частка відбракованих записів і розходження між джерелами виводяться в моніторинг — за ними видно, деградують дані чи ні.
Як це вбудується в поточну платформу?
Підключаємося через програмний інтерфейс і обмін подіями, без перенесення баз і зміни сховища. Рекомендації віддаємо як готові оцінки або як набір факторів — формат узгоджуємо, повернення до попередньої логіки залишається доступним.
Обговоримо задачу: що надіслати для оцінки та плану робіт
Оцінка рекомендаційної системи криптоактивів розраховується не за обсягом коду, а за кількістю джерел, які потрібно звести в один багатофакторний скоринг. Нижче — що надіслати, щоб ми повернулися з оцінкою та планом робіт, а не з уточнювальними питаннями через тиждень.
- Точки інтеграції. Перелічіть системи, звідки беруться дані: біржові канали, гаманці, внутрішні бази, аналітичні вивантаження. Позначте, чи є потоковий прийом або лише вивантаження за розкладом — від цього залежить архітектура перерахунку.
- Доступи до даних. Тестовий контур і read-only-доступи до сховищ, пісочниці біржових джерел. Продуктивні ключі на першому етапі не потрібні — працюємо на копіях і знеособлених зрізах.
- Набір факторів скорингу. Що вже враховується: дохідність за періоди, волатильність, ліквідність, он-чейн-активність, концентрація власників. Які ваги вважаєте робочими і де вони розходяться з практикою.
- Поточні метрики. Як зараз формується рекомендація, скільки часу займає перерахунок, яка частка сигналів доходить до користувача, де фіксуються розходження з ручними рішеннями аналітиків.
- Цільові сценарії. Що має видавати система: ранжування списку, оцінку ризику за портфелем, сигнал на вхід або вихід. Формат відповіді — екран, вивантаження, повідомлення.
- Обмеження та правила. Вимоги комплаєнсу, дисклеймери, регіональні обмеження, історія рішень для розбору спірних випадків.
Якщо частини даних немає — опишіть словами, на старті її замінить ручне вивантаження або історичний зріз. Надсилайте те, що є: за цим набором повернемося з оцінкою трудовитрат, складом етапів і планом робіт.
