Розробка AI-системи персонального інвестиційного портфеля

Чому AI-інвестиційна система помиляється на живих даних

На історичних даних AI-інвестиційна система показує акуратний прогноз, а на живому потоці помилка прогнозу зростає в рази. Причина зазвичай не в самій моделі, а в тому, що навчання йшло на очищеному й синхронізованому ряді, якого в реальній торгівлі не існує.

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

Різні джерела розходяться в цінах закриття та в трактуванні корпоративних подій, і ця розбіжність потрапляє прямо у входи.

Другий фактор — дрейф моделі при зміні режиму ринку. Ознаки, які працювали в спокійному тренді, втрачають значущість у період високої волатильності: розподіл входів з'їжджає, а зв'язки, вивчені на минулому режимі, продовжують застосовуватися без перегляду.

Третій — затримка надходження даних і ручні правки в обліку активів. Поки котирування та корпоративні події доходять до системи, позиції встигають змінитися: спліти, дивіденди й перекази між рахунками вносять вручну, і модель оцінює портфель, якого вже немає.

У сумі це дає системну помилку прогнозу, непомітну на тестовій вибірці. Розбираємо, як вона закривається — від контролю якості даних до детекторів дрейфу й регулярного звіряння обліку активів.

Що змінюється після впровадження: ефект у вимірюваних величинах

Рекомендації перестають збиратися вручну за розрізненими таблицями. Система сама підтягує котирування та корпоративні події, рахує метрики за кожним інструментом і віддає аналітику готову чернетку з обґрунтуванням.

Час на підготовку однієї рекомендації скорочується з годин до хвилин, а ручні операції зводяться до перевірки й підтвердження.

Контроль ризику портфеля вбудований у контур до виконання угоди.

Ліміти на частку одного інструмента, галузеву концентрацію, кореляцію з поточними позиціями та допустиму просадку перевіряються автоматично — частина заявок відсікається ще до того, як потрапить до людини, і за кожною зберігається причина відмови. Ризик перестає залежати від того, хто сьогодні чергує.

Відтворюваність рішень тримається на версіонуванні: вхідні дані, набір правил і версія моделі фіксуються на момент розрахунку. Через місяць будь-яку рекомендацію можна підняти й показати, на яких цифрах вона побудована. Це водночас захист від претензій і матеріал для налаштування стратегії.

Джерело даних — нормалізовані котирування та корпоративні події зовнішніх постачальників на кшталт Bloomberg; розбіжності з обліковою системою розбирає окремий звіт, а не людина.

Підсумок видно у трьох величинах: швидкість підготовки рекомендацій, частка автоматично відсічених ризикованих угод і частка рішень, відтворюваних без ручного розбору.

Формати побудови: готове ядро, донавчання, власна модель

Вибір формату задає не амбіція, а те, наскільки ваша логіка відрізняється від типової. Якщо правила вкладаються у стандартні сценарії — профіль ризику, коридори ребалансування, ліміти за інструментами — виграє готове ядро: його швидше вивести в роботу й простіше супроводжувати.

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

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

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

Етапи впровадження: від аудиту даних до передачі в експлуатацію

Впровадження AI-системи для портфеля починається не з моделі, а з інвентаризації даних, на яких вона вчитиметься.

Порядок етапів фіксований: якщо пропустити аудит джерел або перевірку на історії, на виході отримаємо правдоподібні, але невідтворювані рекомендації та просадку на реальних угодах.

1. Аудит джерел даних. Збираємо все, що вже є: котирування, корпоративні дії, звітність емітентів, макроекономічні ряди, вивантаження з брокерських систем.

   Перевіряємо повноту, частоту оновлення, пропуски, перерахунки заднім числом і права на використання — без цього модель вчиться на дірявому ряді.

2. Схема ознак. З сирих рядів будуємо ознаки: дохідність на різних горизонтах, волатильність, кореляції, режими ринку, метрики ризику. За кожною ознакою фіксуємо вікно розрахунку й затримку подачі, щоб у навчання не потрапляли дані з майбутнього.

3. Цільові функції та правила ризику. Домовляємося, що оптимізуємо — дохідність за заданого ризику, просадку чи частки класів активів. Одразу задаємо межі: ліміти на один інструмент, галузь, частку емітента.

4. Налаштування та навчання. Розмічаємо історію, розділяємо періоди на навчальні й перевірні без перемішування, добираємо параметри моделі.

5. Перевірка на історичних періодах. Прогонимо систему кількома ринковими режимами, включно з кризовими ділянками, і порівнюємо з базовими стратегіями. Дивимося просадку, стійкість результату й кількість угод.

6. Приймання та здача в експлуатацію. Передаємо регламент перенавчання, контроль дрейфу даних і метрик, поріг автоматичного відключення й документацію команді замовника.

Склад постачання: конфігурація, схеми даних і регламенти

Сама модель — лише частина системи: навколо неї залишаються конфігурація, дані, права й процедури.

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

Тому постачання фіксуємо як комплект артефактів: за кожним можна провести приймання й передати супровід іншому інженеру без усних пояснень.

• Конфігурація рішення — горизонти розрахунку, обмеження щодо ризику та правила формування портфеля винесені в окремі файли, а не «зашиті» в код. Зміна ліміту не потребує перезбирання й нового релізу.
• Схеми потоків даних — шлях від джерела котирувань і корпоративних подій до вітрини ознак і видачі рекомендацій: де нормалізація, де контроль якості, де точка відмови й як вона обробляється.
• Політики доступу — ролі аналітика, ризик-менеджера й супроводу: хто бачить історичні дані, хто змінює конфігурацію, хто запускає перенавчання, з журналом дій за кожною зміною.
• Документація — опис моделі, перелік ознак та їхніх джерел, обмеження застосовності (які ринкові режими не покриті) та інструкція з експлуатації для чергової зміни.
• Регламент перенавчання — тригери (дрейф розподілу ознак, падіння якості на відкладеній вибірці), періодичність, порядок валідації та умови відкату до попередньої версії.
• Набір перевірок і план відновлення — автотести на пропуски, викиди й розбіжність з еталонним розрахунком плюс опис, де зберігаються попередні версії моделі та конфігурації й за який час система повертається в роботу.

Кейс: як скоротилася частка ручних перевірок портфеля

До: розрахунки й звіряння жили в різних таблицях

Управлінська команда Aurum Capital збирала модельні портфелі вручну: аналітик переносив цільові ваги з розрахункової моделі, ризик-менеджер звіряв їх з лімітами за окремим файлом, трейдер оформлював заявки ще в одній системі.

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

Що змінили в контурі ухвалення рішень

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

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

• Частка ручних перевірок портфеля: 100% → 18% — автоматика звіряє ваги й ліміти, аналітик розбирає лише винятки.
• Повний перегляд портфеля: 4 години → 25 хвилин разом із погодженням.
• Порушення лімітів, знайдені після угоди: з 7 за квартал до нуля — перевірка стоїть до постановки заявки.
• Відкат до попередньої версії моделі: замість відновлення таблиць з пам'яті — одна операція зі збереженим контекстом рішення.

Чим відрізняється рекомендаційна система від автоторгового робота

Різниця не в моделі, а в точці, де розрахунок переходить у дію. Рекомендаційна схема видає сигнал з обґрунтуванням — інструмент, частка, причина спрацювання, — а заявку вводить людина. Автоторговий робот замикає контур сам: сигнал одразу стає заявкою, і людини в циклі немає.

Звідси розходяться швидкість реакції та клас ризику. Рекомендаційній схемі досить перерахунку раз на день або за подією — темп задає людина. Автоматичному виконанню потрібен постійний перерахунок і стійкий канал до брокера, інакше прослизання з'їдає ефект стратегії. Помилка моделі в першому випадку коштує втраченою угодою, у другому — виконаною заявкою.

На практиці вибирають не «або», а місце межі. Зазвичай рекомендаційна схема відповідає за зміну структури портфеля, а автоматичне виконання — за ребалансування й захисні дії під жорсткими лімітами.

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

Технічні сумніви: дрейф моделі, дані, відповідальність

Три питання повертаються на кожному захисті проєкту: що буде, коли ринок змінить режим, що робити з пропусками в даних і хто відповідає за підсумкове рішення.

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

Дрейф моделі — це розбіжність між даними, на яких її навчали, і поточною поведінкою ринку. Ми відстежуємо розподіл вхідних ознак, стійкість важливості факторів і розбіжність прогнозу з фактом на ковзному вікні; коли метрики виходять за поріг, запускається перенавчання.

Кожна версія зберігається разом із набором даних і налаштуваннями, тому повернення до попередньої версії не потребує перезбирання.

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

Якщо даних бракує, система не домалює їх, а позначає розрахунок як неповний і переходить у режим спостереження.

Що робити, якщо за інструментом немає даних?

Рекомендація не видається, розрахунок позначається як неповний, подія потрапляє до журналу моніторингу. Розбіжність між основним і резервним джерелом видно у звіті, тому прогалина виявляється до того, як потрапить до портфеля.

Хто відповідає за інвестиційне рішення?

Система готує розрахунок, обґрунтування й перелік припущень; рішення ухвалює людина — аналітик або керуючий. Розмежування фіксується регламентом: за якість даних, роботу моделі та журнал рішень відповідаємо ми, за інтерпретацію й угоду — ваша сторона.

Що обговорити на першій зустрічі щодо вашого завдання

Перша зустріч потрібна не для презентації, а для збору ввідних, від яких напряму залежить оцінка обсягу робіт. Чим конкретніші відповіді про дані, обмеження й ролі, тим менше припущень залишається в плані, а терміни до першого робочого контуру стають передбачуваними.

• Джерела даних: які вивантаження з брокерських і банківських кабінетів є зараз, у якому вигляді надходять, як часто оновлюються і хто видає доступ.
• Глибина історії операцій: за який період є угоди й як у них відображені корпоративні дії — поповнення, виплати, дроблення.
• Поточний процес ухвалення рішень: хто вирішує про купівлю чи продаж, на які звіти дивиться і скільки часу це займає сьогодні.
• Обмеження проєкту: які інструменти вже використовуються, що не можна змінювати, які вимоги до зберігання даних і розмежування доступу.
• Ролі в команді: хто з боку замовника відповідає за дані, хто підтверджує інвестиційну логіку, хто приймає результат.
• Терміни й контрольні точки: до якої дати потрібен перший робочий контур і які етапи можна вести паралельно.

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