Розробка AI-системи оптимізації портфеля: де ламається логіка
Портфель ламається не в момент угоди, а в момент, коли рішення ухвалюється за вчорашньою картиною світу. Дані щодо цін, ліквідності та факторів надходять із різною частотою, частина — із затримкою на добу й більше.
Модель, навчена на узгоджених рядах, на живих даних бачить не ринок, а його знімок тижневої давності, і запізнення сигналів перетворюється на систематичний зсув рішення.
Друга точка відмови — регламент ребалансування. Календарне правило раз на місяць і фіксований поріг відхилення ваги зручні та передбачувані, але реагують на вже минулий рух.
Ручне ребалансування між планами додає людський фактор: рішення ухвалюються нерівномірно, частина позицій залишається переваженою тижнями, а витрати на угоди ніхто не зіставляє з виграшем за ризиком.
На різкому зсуві ринку обидві проблеми складаються. Кореляції, які в спокійному режимі різні, сходяться до одиниці, і весь ризик опиняється в одному факторі замість диверсифікованого набору.
Історична оцінка спільних рухів у такий момент недооцінює їхній масштаб, тому просадка під час зсуву ринку приходить швидше, ніж її встигає відпрацювати правило.
Суть у розриві між свіжістю сигналу й швидкістю рішення: сам оптимізатор може бути коректним, але отримує вхід, якого вже немає.
Розбираємо, як це закривається — як сигнальний шар на ML прибирає запізнення і чому навчання з підкріпленням переносить вибір моменту й обсягу угоди з регламенту в саму політику.
Ефекти впровадження: швидкість реакції та стійкість портфеля
Ефект від AI-системи оптимізації портфеля видно не в точності окремого прогнозу, а в поведінці портфеля на нестабільному ринку. Нижче — метрики, за якими ми разом із замовником звіряємо результат впровадження.
Швидкість реакції на сигнал
Модель перераховує цільові ваги й передає їх у виконання в межах одного торгового циклу: між появою сигналу та заявкою минає час, заданий регламентом, а не зайнятістю чергового. На історичних прогонах реакція стискається з годин до хвилин — сигнал не встигає застаріти в дорозі.
Стійкість портфеля
Ліміти на концентрацію, галузеву структуру, волатильність і кореляції задані прямо в правилах ризику та у функції винагороди, тому модель не може піти в одну ідею. Просадка на схожих ділянках ринку стає передбачуваною, а набір ваг — стійким від циклу до циклу.
Зменшення ручних правок
Частка сигналів, що пройшли без втручання людини, — пряма метрика довіри до системи. Перевірки вхідних даних і жорсткі обмеження знімають рутину: ручних коригувань залишаються одиниці на сотню рішень, і майже всі пов’язані з корпоративними подіями, а не з помилками моделі.
Усунені класи відмов
Окремо ведемо перелік відмов, закритих на рівні архітектури: розбіжність даних і фактичних позицій, виконання за застарілою котировкою, обхід ліміту ручною заявкою, зупинка розрахунку під час збою джерела. Кожен клас отримує свою автоматичну перевірку — повернення до попередньої поведінки видно одразу.
Підходи до побудови моделі: порівняння режимів
Вибір контуру визначається не тим, наскільки метод сучасний, а тим, як у ньому формалізовано ризик-обмеження і як часто змінюються статистичні властивості даних. На практиці порівнюють чотири режими — від детермінованих правил до навчуваної політики.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила на порогах | Потрібні прозорість і швидкий аудит: ліміти на частку інструмента, просадку, ліквідність | Не бачить зміни кореляцій, кожна правка — ручне переналаштування |
| Класична оптимізація | Є стійкі оцінки дохідності та ризику, потрібен зрозумілий склад портфеля | Чутлива до помилки вхідних оцінок, втрачає стійкість при зміні режиму |
| Навчання з підкріпленням | Є середовище симуляції, мета — динамічне ребалансування з урахуванням витрат | Потребує багато даних, винагороду легко підлаштувати, рішення важко пояснити |
| Гібридний контур | Правила тримають жорсткі ліміти, модель шукає рішення в межах допустимої області | Складніший у супроводі: контроль дрейфу, версіонування політик |
Гібридний режим зазвичай дає найкращий компроміс: межі ризику залишаються детермінованими й перевірюваними, а модель працює лише там, де є простір для рішення.
У побудові AI-системи для оптимізації портфеля правила не скасовуються — вони залишаються обов’язковим шаром, а навчання й оптимізація стають надбудовою над ними.
Етапи роботи: від аудиту даних до передачі моделі
Роботу будуємо так, що кожен етап закінчується артефактом, який можна перевірити, а не усним «готово».
Перескочити крок не можна: якщо пропустити аудит даних, модель упевнено вивчить закономірності там, де в історії просто не вистачає паперів, а помилка спливе вже на реальному портфелі.
-
Аудит даних. Перевіряємо глибину й повноту історії, пропуски та розриви, коректність цін закриття, корпоративні події, емітентів, що вижили й зникли, збіжність кількох джерел.
На виході — звіт про якість рядів і список інструментів, за якими модель взагалі має право ухвалювати рішення.
-
Постановка мети й обмежень. Фіксуємо, що саме оптимізуємо: дохідність за заданого рівня ризику, відхилення від еталонного портфеля або стійкість просадки.
Обмеження записуємо формально — ліміти на частку одного інструмента, галузеві квоти, вимоги до ліквідності, заборона коротких позицій, витрати угоди.
-
Схема контуру. Описуємо, як система живе в робочому режимі: звідки надходять дані та з якою періодичністю, де вважається сигнал, хто підтверджує зміни складу, як виконується угода і де зберігається історія всіх ухвалених рішень для подальшого розбору.
-
Навчання моделі. Навчаємо з урахуванням режимів ринку та транзакційних витрат, перевіряючи стійкість до зміни волатильності. Окремо контролюємо перенавчання: модель має показувати результат і на даних, яких не бачила.
-
Перевірка на історичних зрізах. Прогоняємо стратегію по ковзних вікнах — навчання лише на минулому, перевірка на наступній ділянці. Рахуємо витрати, прослизання та поведінку в стресових періодах, порівнюємо з простим базовим портфелем.
-
Передача моделі та навчання команди. Віддаємо документацію, регламент оновлення й моніторинг деградації якості, проводимо розбір з аналітиками та ризик-менеджментом, щоб систему можна було розвивати без нас.
Що передаємо на руки: код, схеми, регламенти
Після здачі в команди замовника залишається не «чорна скринька», а робоча система з повним комплектом описів. Передати її можна своїй команді розробки або іншому підряднику без зворотного розбору логіки: усі рішення, параметри й точки контролю зафіксовані в артефактах.
- Документація моделі — які ознаки та дані використовуються, що максимізується, які обмеження щодо ризику зашиті, як модель поводиться на різних ринкових режимах.
- Схема контуру ухвалення рішень — шлях від ринкових даних і прогнозу до заявки, з точками контролю, лімітами й ручним вето.
- Політики доступу — ролі, розмежування прав на дані й параметри, журнал змін і порядок погодження правок.
- Регламент перенавчання — тригери запуску, вікно навчальної вибірки, порядок валідації та відкат на попередню версію.
- Моніторинг дрейфу — контроль зсуву розподілів входу й деградації метрик, пороги оповіщень і порядок реакції.
- Конфігурації середовища — зафіксовані залежності та автоскладання: повторний запуск дає той самий результат на тих самих даних.
- Інструкції з експлуатації — як додати інструмент, оновити набір ознак, прочитати звіт і провести перевірку перед випуском.
Окремо передаємо результати перевірок на історичних періодах і на утримуваній вибірці — з чесним описом того, де підхід працює гірше, а не лише там, де він виграє.
Кейс: як змінилося управління резервами після впровадження
Портфель резервів до впровадження вівся в ручному режимі: склад переглядали за календарем, а рішення збирали з кількох незв’язаних таблиць. На реакцію йшов робочий день і більше, тому частину просадки закривали постфактум. Метрики нижче знято по одному портфелю на зіставних за волатильністю періодах до й після запуску.
| Метрика | До впровадження | Після |
|---|---|---|
| Частка рішень, ухвалених вручну | майже всі | близько п’ятої частини — погодження великих зсувів |
| Час реакції на зміну умов | робочий день і більше | хвилини, автоматичний тригер |
| Глибина просадки на несприятливій ділянці | 16–18% | 7–9% |
| Позапланові правки складу | 3–4 на місяць | 1 на квартал |
| Ребалансування | за календарем, раз на квартал | за виходом за коридор ризику |
Що саме змінили
Заміна ручних рішень моделлю була наслідком, а не метою. Спочатку формалізували ризик-профіль і коридори допустимих ваг, потім навчили агента на історії самого портфеля — підходи до розмітки та валідації взяли з Advances in Financial Machine Learning.
Ребалансування прив’язали до тригера за ризиком, а не до дати, тому позапланових правок стало менше за більшої частоти спрацювань.
Розробка AI-системи оптимізації портфеля включала журнал рішень: кожна зміна ваги зберігається з набором ознак, на яких її ухвалено. Це дало розбір інциденту й відкат за хвилини замість відновлення логіки з листування.
Час реакції перестав бути обмеженням — вузьким місцем стала лише процедура погодження великих зсувів.
Чим навчання з підкріпленням відрізняється від класичної оптимізації
Класична оптимізація працює з фіксованою постановкою: задано очікувані дохідності та матрицю коваріацій, потрібно знайти ваги, що максимізують дохідність за заданого ризику й обмежень.
Це квадратичне завдання, яке розв’язується детерміновано — той самий вхід завжди дає той самий портфель, результат відтворюваний, зрозумілий і легко перевіряється.
Підхід Марковіца Markowitz та його практичні модифікації залишаються робочою основою: зрозуміла логіка, швидкий перерахунок, простий відкат до попередньої алокації.
Схема ламається там, де рішення впливає на наступне. Витрати угоди, прослизання та доступна ліквідність залежать від послідовності дій: агресивне ребалансування сьогодні з’їдає дохідність завтра.
Навчання з підкріпленням саме про це — агент взаємодіє із середовищем, а не з одним статичним зрізом даних, і оптимізує накопичений результат на горизонті, а не на одному кроці. Це дає змогу враховувати наслідки рішень, а не лише їхню миттєву оцінку.
Ціна такої гнучкості — складність впровадження. Потрібна модель середовища, яка правдоподібно відтворює витрати й ліквідність; за неправильно заданої мети агент знаходить вигідну для себе, але безглузду для бізнесу поведінку.
Навчання чутливе до початкових умов, тому фіксуються генератори випадковості, версії середовища й метрик, а результат проходить перевірку на даних поза навчальною вибіркою.
На практиці ми майже завжди збираємо гібрид: класичний оптимізатор задає базову алокацію та жорсткі обмеження щодо ризику, а агент працює поверх — із таймінгом ребалансування й адаптацією до режиму ринку.
Стійкість рішень забезпечують запобіжники: ліміти на обіг, обмеження відхилення від базових ваг, автоматичний відкат до класичного розрахунку при виході метрик за коридор.
Технічні сумніви: дані, стійкість, контроль
Замовники приходять зі схожим набором сумнівів: чи вистачить історичних даних, чи не виявиться модель підігнаною під вдалий період, хто відповідає за її рекомендації та як це вбудується в уже робочий контур. Відповідаємо по суті — без обіцянок «універсальної» моделі.
Даних мало і вони різнорідні — що робити?
Збираємо вітрину з кількох джерел, приводимо інструменти до єдиної частоти й спільного торгового календаря, окремо позначаємо періоди зміни режиму ринку.
Коли історії об’єктивно не вистачає, розширюємо вибірку за рахунок крос-секції за інструментами, додаємо стрес-сценарії та перевіряємо стійкість на відкладеному періоді.
Якщо даних усе одно недостатньо — фіксуємо це у звіті й скорочуємо горизонт застосування, а не підганяємо результат.
Як ви контролюєте перенавчання?
Валідація йде послідовними вікнами: навчання на минулому, перевірка на наступній ділянці з обов’язковим розривом між ними, щоб унеможливити витік майбутніх значень.
Складність моделі обмежуємо числом ознак і штрафами, а розходження метрик усередині вибірки та поза нею тримаємо під моніторингом. Зростаючий розрив — стоп-сигнал: модель не випускаємо, доки причину не усунено.
Хто відповідає за рішення системи?
Система видає рекомендації з обґрунтуванням: внесок факторів, очікуваний ризик, поведінка в сценаріях. Фінальне рішення залишається за інвестиційним комітетом, є ручний режим і жорсткі ліміти, а всі дії логуються. Відповідальність не передається алгоритму — вона закріплена в регламенті.
Як це вбудувати в робочий контур?
Дотримуємося CRISP-DM за етапами життєвого циклу: пілот іде в окремому контурі на копії даних, доступ до продуктивного середовища — лише на читання.
Зв’язок з обліковими системами — через програмний інтерфейс і черги обміну, розкочування на частину портфеля з можливістю відкотити версію.
Обговоримо задачу: що підготувати до першої зустрічі
Перша зустріч окупається, коли на ній є фактура. Без неї обговорення задачі переходить у загальні слова, а оцінка перетворюється на вилку «від і до» — і ми, і ви витрачаємо другу зустріч на те, що можна було зняти одразу.
Нижче — мінімум, який дає змогу нашим інженерам перейти до оцінки та плану робіт після однієї розмови.
- Поточний контур рішень: як портфель формується зараз — за правилом, за календарем чи за відхиленням від цільових часток, хто затверджує зміни, де зберігається історія версій портфеля.
- Вимоги до даних: джерела котирувань і угод, глибина історії, валюта та часовий пояс обліку, корпоративні дії (дивіденди, дроблення), як обробляються пропуски та викиди. Формат вивантаження — CSV або Parquet, разове воно чи за розкладом.
- Обмеження щодо ризику: ліміти на інструмент і на сектор, допустима просадка, список заборонених активів, вимоги регламенту або регулятора, які не можна порушувати за жодного сценарію.
- Доступи та середовище: доступ до даних лише на читання, тестовий контур брокера, куди система віддає результат — файл, таблиця або виклик із вашої облікової системи.
- Критерії приймання: чим вимірюємо результат — дохідність щодо еталонного портфеля, максимальна просадка, частка ручних втручань у рекомендації.
- Склад команди та ролі: хто відповідає за дані, хто за ризик-контроль, хто ухвалює фінальне рішення щодо угоди.
Якщо чогось зі списку немає під рукою — не страшно, частину закриваємо самі на етапі розбору даних. Опишіть задачу у вільній формі: повернемося з оцінкою, планом етапів і тим, які дані знадобляться першими.
