Розробка ШІ-системи ребалансування портфеля

Ребалансування портфеля з AI: де ламається процес

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

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

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

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

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

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

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

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

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

Після впровадження ребалансування портфеля з AI перестає бути періодичною процедурою — контур рахує відхилення за кожною позицією постійно й розділяє внески ринку та притоків.

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

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

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

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

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

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

Порівняння підходів: правила, модель, комбінований контур

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

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

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

Порядок робіт: від аудиту даних до запуску

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

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

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

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

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

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

6. Передавання в супровід. Регламент експлуатації, контрольні метрики, процедура відкату до попередньої версії правил, навчання команди.

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

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

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

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

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

Кейс: як прибрали дрейф часток між класами активів

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

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

Зібрали сервіс, який щоночі знімає позиції та котирування (джерело — Interactive Brokers), рахує поточні ваги й порівнює їх із цільовою структурою.

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

Результат у метриках: середньоквадратичне відхилення від цільової структури знизилося з 4,8 до 0,7 п.п., перевірка йде щоденно замість разу на квартал.

Ручних операцій на місяць залишилося 3–4 замість сорока — аналітик підтверджує або відхиляє готовий набір, а не перераховує ваги. Підготовка рішення скоротилася з двох днів до 15 хвилин, клас відмов «заявка пішла повз ліміт» перестав відтворюватися.

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

Чим модельне ребалансування відрізняється від правил?

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

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

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

Якщо історія зібрана «як зараз», метрики якості виходять завищеними й у реальній торгівлі не відтворюються.

Модель деградує мовчки: зв'язок факторів із дохідністю змінюється, ознаки зсуваються, рішення залишається зовні коректним, але втрачає сенс.

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

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

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

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

Питання, які ставлять перед стартом

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

Що якщо дані надійшли неповними?

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

Що відбувається в разі збою розрахунку?

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

Як це вбудовується в облікову систему?

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

Як переглядаються пороги?

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

Обговоримо задачу й повернемося з оцінкою та планом

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

• Вихідні дані: які джерела котирувань, угод і поточних позицій доступні, з якою глибиною історії та частотою оновлення, як обробляються пропуски й розбіжності між системами.
• Що вважаємо відхиленням: цільові частки за класами активів, допустимі коридори й поріг спрацювання — за часом, за величиною відходу або комбіновано.
• Контроль ризику: жорсткі обмеження, які система не може порушити — ліміти на інструмент, галузь, емітента, частку низьколіквідних позицій, мінімальний залишок.
• Контур виконання: система виставляє заявки сама чи формує рекомендації на підтвердження; як обробляються часткові виконання й відмови.
• Формат звітності: журнал рішень з обґрунтуванням, склад відхилень до й після спрацювання, регулярний звіт за результатами.
• Умови приймання: на яких даних перевіряємо логіку, які показники вважаємо виконанням задачі, як виглядає відкат до попереднього набору правил.

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