AI-система для оптимизации портфеля: ML и RL подходы

Разработка AI-системы оптимизации портфеля: где ломается логика

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

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

На резком сдвиге рынка обе проблемы складываются. Корреляции, которые в спокойном режиме разные, сходятся к единице, и весь риск оказывается в одном факторе вместо диверсифицированного набора. Историческая оценка совместных движений в такой момент недооценивает их масштаб, поэтому просадка при сдвиге рынка приходит быстрее, чем её успевает отработать правило.

Суть в разрыве между свежестью сигнала и скоростью решения: сам оптимизатор может быть корректен, но получает вход, которого уже нет. Разбираем, как это закрывается — как сигнальный слой на ML убирает запаздывание и почему обучение с подкреплением переносит выбор момента и объёма сделки из регламента в саму политику.

Эффекты внедрения: скорость реакции и устойчивость портфеля

Эффект от AI-системы оптимизации портфеля виден не в точности отдельного прогноза, а в поведении портфеля на нестабильном рынке. Ниже — метрики, по которым мы вместе с заказчиком сверяем результат внедрения.

Скорость реакции на сигнал

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

Устойчивость портфеля

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

Снижение ручных правок

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

Устранённые классы отказов

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

Подходы к построению модели: сравнение режимов

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

Гибридный режим обычно даёт лучший компромисс: границы риска остаются детерминированными и проверяемыми, а модель работает только там, где есть пространство для решения. В построении AI-системы для оптимизации портфеля правила не отменяются — они остаются обязательным слоем, а обучение и оптимизация становятся надстройкой над ними.

Этапы работы: от аудита данных до передачи модели

Работу строим так, что каждый этап заканчивается артефактом, который можно проверить, а не устным «готово». Перескочить шаг нельзя: если пропустить аудит данных, модель уверенно выучит закономерности там, где в истории просто не хватает бумаг, а ошибка всплывёт уже на реальном портфеле.

1. Аудит данных. Проверяем глубину и полноту истории, пропуски и разрывы, корректность цен закрытия, корпоративные события, выживших и исчезнувших эмитентов, сходимость нескольких источников. На выходе — отчёт о качестве рядов и список инструментов, по которым модель вообще имеет право принимать решения.

2. Постановка цели и ограничений. Фиксируем, что именно оптимизируем: доходность при заданном уровне риска, отклонение от эталонного портфеля или устойчивость просадки. Ограничения записываем формально — лимиты на долю одного инструмента, отраслевые квоты, требования по ликвидности, запрет коротких позиций, издержки сделки.

3. Схема контура. Описываем, как система живёт в рабочем режиме: откуда приходят данные и с какой периодичностью, где считается сигнал, кто подтверждает изменения состава, как исполняется сделка и где хранится история всех принятых решений для последующего разбора.

4. Обучение модели. Учим с учётом режимов рынка и транзакционных издержек, проверяя устойчивость к смене волатильности. Отдельно контролируем переобучение: модель должна показывать результат и на данных, которых не видела.

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

6. Передача модели и обучение команды. Отдаём документацию, регламент обновления и мониторинг деградации качества, проводим разбор с аналитиками и риск-менеджментом, чтобы систему можно было развивать без нас.

Что передаём на руки: код, схемы, регламенты

После сдачи у команды заказчика остаётся не «чёрный ящик», а рабочая система с полным комплектом описаний. Передать её можно своей команде разработки или другому подрядчику без обратного разбора логики: все решения, параметры и точки контроля зафиксированы в артефактах.

• Документация модели — какие признаки и данные используются, что максимизируется, какие ограничения по риску зашиты, как модель ведёт себя на разных рыночных режимах.
• Схема контура принятия решений — путь от рыночных данных и прогноза до заявки, с точками контроля, лимитами и ручным вето.
• Политики доступа — роли, разграничение прав на данные и параметры, журнал изменений и порядок согласования правок.
• Регламент переобучения — триггеры запуска, окно обучающей выборки, порядок валидации и откат на предыдущую версию.
• Мониторинг дрейфа — контроль смещения распределений входа и деградации метрик, пороги оповещений и порядок реакции.
• Конфигурации окружения — зафиксированные зависимости и автосборка: повторный запуск даёт тот же результат на тех же данных.
• Инструкции по эксплуатации — как добавить инструмент, обновить набор признаков, прочитать отчёт и провести проверку перед выпуском.

Отдельно передаём результаты проверок на исторических периодах и на удержанной выборке — с честным описанием того, где подход работает хуже, а не только там, где он выигрывает.

Кейс: как изменилось управление резервами после внедрения

Портфель резервов до внедрения вёлся в ручном режиме: состав пересматривали по календарю, а решения собирали из нескольких несвязанных таблиц. На реакцию уходил рабочий день и больше, поэтому часть просадки закрывали постфактум. Метрики ниже сняты по одному портфелю на сопоставимых по волатильности периодах до и после запуска.

Что именно изменили

Замена ручных решений моделью была следствием, а не целью. Сначала формализовали риск-профиль и коридоры допустимых весов, затем обучили агента на истории самого портфеля — подходы к разметке и валидации взяли из Advances in Financial Machine Learning. Ребалансировку привязали к триггеру по риску, а не к дате, поэтому внеплановых правок стало меньше при большей частоте срабатываний.

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

Чем обучение с подкреплением отличается от классической оптимизации

Классическая оптимизация работает с фиксированной постановкой: даны ожидаемые доходности и матрица ковариаций, требуется найти веса, максимизирующие доходность при заданном риске и ограничениях. Это квадратичная задача, которая решается детерминированно — один и тот же вход всегда даёт один и тот же портфель, результат воспроизводим, объясним и легко проверяется. Подход Марковица Markowitz и его практические модификации остаются рабочей основой: понятная логика, быстрый пересчёт, простой откат к предыдущей аллокации.

Схема ломается там, где решение влияет на следующее. Издержки сделки, проскальзывание и доступная ликвидность зависят от последовательности действий: агрессивная ребалансировка сегодня съедает доходность завтра. Обучение с подкреплением как раз про это — агент взаимодействует со средой, а не с одним статичным срезом данных, и оптимизирует накопленный результат на горизонте, а не на одном шаге. Это позволяет учитывать последствия решений, а не только их мгновенную оценку.

Цена такой гибкости — сложность внедрения. Нужна модель среды, которая правдоподобно воспроизводит издержки и ликвидность; при неверно заданной цели агент находит выгодное для себя, но бессмысленное для бизнеса поведение. Обучение чувствительно к начальным условиям, поэтому фиксируются генераторы случайности, версии среды и метрик, а результат проходит проверку на данных вне обучающей выборки.

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

Технические сомнения: данные, устойчивость, контроль

Заказчики приходят с похожим набором сомнений: хватит ли исторических данных, не окажется ли модель подогнанной под удачный период, кто отвечает за её рекомендации и как это встроится в уже работающий контур. Отвечаем по существу — без обещаний «универсальной» модели.

Как вы контролируете переобучение?

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

Кто отвечает за решения системы?

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

Как это встроить в работающий контур?

Соблюдаем CRISP-DM по этапам жизненного цикла: пилот идёт в отдельном контуре на копии данных, доступ к продуктивной среде — только на чтение. Связь с учётными системами — через программный интерфейс и очереди обмена, раскатка на часть портфеля с возможностью откатить версию.

Обсудим задачу: что подготовить к первой встрече

Первая встреча окупается, когда на ней есть фактура. Без неё обсуждение задачи уходит в общие слова, а оценка превращается в вилку «от и до» — и мы, и вы тратим вторую встречу на то, что можно было снять сразу. Ниже — минимум, который позволяет нашим инженерам перейти к оценке и плану работ после одного разговора.

• Текущий контур решений: как портфель формируется сейчас — по правилу, по календарю или по отклонению от целевых долей, кто утверждает изменения, где хранится история версий портфеля.
• Требования к данным: источники котировок и сделок, глубина истории, валюта и часовой пояс учёта, корпоративные действия (дивиденды, дробления), как обрабатываются пропуски и выбросы. Формат выгрузки — CSV или Parquet, разовая она или по расписанию.
• Ограничения по риску: лимиты на инструмент и на сектор, допустимая просадка, список запрещённых активов, требования регламента или регулятора, которые нельзя нарушать ни при каком сценарии.
• Доступы и среда: доступ к данным только на чтение, тестовый контур брокера, куда система отдаёт результат — файл, таблица или вызов из вашей учётной системы.
• Критерии приёмки: чем измеряем результат — доходность относительно эталонного портфеля, максимальная просадка, доля ручных вмешательств в рекомендации.
• Состав команды и роли: кто отвечает за данные, кто за риск-контроль, кто принимает финальное решение по сделке.

Если чего-то из списка нет под рукой — не страшно, часть закрываем сами на этапе разбора данных. Опишите задачу в свободной форме: вернёмся с оценкой, планом этапов и тем, какие данные понадобятся первыми.