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

Почему AI инвестиционная система ошибается на живых данных

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

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

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

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

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

Что меняется после внедрения: эффект в измеримых величинах

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

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

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

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

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

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

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

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

Этапы внедрения: от аудита данных до передачи в эксплуатацию

Внедрение AI-системы для портфеля начинается не с модели, а с инвентаризации данных, на которых она будет учиться. Порядок этапов фиксирован: если пропустить аудит источников или проверку на истории, на выходе получим правдоподобные, но невоспроизводимые рекомендации и просадку на реальных сделках.

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

2. Схема признаков. Из сырых рядов строим признаки: доходность на разных горизонтах, волатильность, корреляции, режимы рынка, метрики риска. У каждого признака фиксируем окно расчёта и задержку подачи, чтобы в обучение не попадали данные из будущего.

3. Целевые функции и правила риска. Договариваемся, что оптимизируем — доходность при заданном риске, просадку или доли классов активов. Сразу задаём границы: лимиты на один инструмент, отрасль, долю эмитента.

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

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

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

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

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

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

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

До: расчёты и сверка жили в разных таблицах

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

Что изменили в контуре принятия решений

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

• Доля ручных проверок портфеля: 100% → 18% — автоматика сверяет веса и лимиты, аналитик разбирает только исключения.
• Полный пересмотр портфеля: 4 часа → 25 минут вместе с согласованием.
• Нарушения лимитов, найденные после сделки: с 7 за квартал до нуля — проверка стоит до постановки заявки.
• Откат к предыдущей версии модели: вместо восстановления таблиц по памяти — одна операция с сохранённым контекстом решения.

Чем отличается рекомендательная система от автоторгового робота

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

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

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

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

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

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

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

Что делать, если по инструменту нет данных?

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

Кто отвечает за инвестиционное решение?

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

Что обсудить на первой встрече по вашей задаче

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

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

После встречи мы фиксируем объём, разбиваем его на этапы и возвращаемся с оценкой и планом внедрения — с явным указанием, что делаем мы, а что остаётся на стороне заказчика.