Базовая архитектура хранения и MLOps для ИИ НЕКСУС

commit → тесты → обучение → оценка → ручное одобрение → выкладка в тестовую среду → A/B‑тест → перевод в промышленную среду

1. Логическая схема хранения данных

Слой 1. Операционные данные платформы (OLTP)

Основная база данных НЕКСУС/ГАНИМЕД, из которой данные забирает аналитическая витрина:

• пользователи, роли, результаты проверки KYC;
• проекты, заявки, статусы;
• сделки, платежи, графики выплат;
• события СФОРДЕКС, курсы токенов, обороты;
• журнал действий (аудит) и технические логи.​

Слой 2. Хранилище данных (DWH / «озеро данных») для аналитики и ИИ

• Объектное хранилище (S3‑совместимое или HDFS) — «озеро данных» для сырых событий: логи, клики, обращения к API, события блокчейна.
• Хранилище данных (например, ClickHouse / Snowflake / BigQuery / Postgres + Timescale) — нормализованные витрины для моделей:
  - витрина проектов (финансовые показатели, отрасль, стадия, скоринговые признаки);
  - витрина инвесторов и портфелей;
  - витрина транзакций и погашений;
  - витрина риск‑событий и комплаенс‑кейсов.

Регулярный процесс выгрузки и загрузки данных (ETL/ELT) переносит данные из операционной БД в озеро и хранилище пакетами (каждые 5–15 минут) плюс потоковая синхронизация ключевых событий (создание проекта, инвестиция, дефолт).​

2. Контуры данных для разных задач ИИ

• Контур скоринга проектов
  Исторические проекты: входные параметры, решения риск‑комитета, фактический исход сделки (успех, дефолт, реструктуризация).
• Контур портфелей инвесторов
  Срезы портфелей во времени, доходность, просадки, пополнения и выводы, действия инвестора.
• Контур комплаенса
  Флаги подозрительных операций, проверенные кейсы (одобрено / отказ / эскалация).

Каждый контур хранится как отдельная «зона» в озере данных (сырые данные → очищенные → признаки), чтобы можно было воспроизводить обучающие выборки для моделей.

3. Хранилище признаков (Feature Store)

Чтобы не пересобирать признаки каждый раз с нуля, используется отдельное хранилище признаков, например Feast.

В нём хранятся:

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

Хранилище признаков даёт:

• онлайн‑доступ с малой задержкой — для скоринга в момент показа проекта или оформления сделки;
• офлайн‑доступ — для обучения моделей на исторических данных.

4. Цепочка MLOps (управление жизненным циклом моделей)

Получение данных

• Интеграция с операционными базами данных и блокчейном через события, REST‑ или RPC‑интерфейсы.​
• Очистка, обезличивание и псевдонимизация персональных данных в аналитическом контуре (важно для соблюдения 152‑ФЗ, 259‑ФЗ и требований по информационной безопасности).​

Проверка качества данных

• Формальные схемы данных и проверки (например, Great Expectations или собственные правила).
• Триггеры при аномальной доле пустых значений и неожиданных изменениях распределений.

Обучающий конвейер

• Автоматический запуск обучения по расписанию (раз в сутки/неделю) или по событию (накоплено нужное количество новых кейсов).
• Использование систем типа MLFlow, Kubeflow, Vertex AI или SageMaker для:
  - ведения версий датасетов и моделей;
  - записи метрик качества;
  - хранения артефактов (файлы моделей, веса, конфигурации).

Проверка моделей и управление ими

• Набор тестов: качество классификации (ROC‑AUC, F1, Precision‑Recall), устойчивость, отсутствие перекосов (fairness).
• Бизнес‑правила:
  - модель нельзя вводить в эксплуатацию, если она ухудшает ключевые метрики;
  - обязательно ручное одобрение (риск‑команда / владелец продукта) перед выводом в промышленный контур.

Ввод в эксплуатацию

• Модели разворачиваются как отдельные сервисы (REST/gRPC) в контейнерах/Kubernetes.
• Есть промежуточная среда, где новая версия работает в теневом режиме или через A/B‑тестирование.

Мониторинг

Отслеживаются:

• задержки и ошибки сервиса скоринга;
• дрейф данных (изменение распределений признаков) и дрейф самой задачи;
• бизнес‑метрики: рост или падение дефолтов, доля принятых рекомендаций, удовлетворённость пользователей.

При ухудшении показателей включается откат на прошлую версию модели или автоматический запуск переобучения.

5. Безопасность и соответствие законодательству РФ

С учётом 259‑ФЗ, 115‑ФЗ, 152‑ФЗ и ГОСТов по ИБ инфраструктура ИИ должна:​

• хранить персональные данные в зашифрованном виде, раздельно для идентификаторов и аналитических данных;
• иметь жёсткое разграничение прав доступа (RBAC) и полный аудит доступа к хранилищу данных и хранилищу признаков;
• использовать сертифицированные средства криптографической защиты там, где это требуется (VPN, аппаратные токены администраторов, модули доверенной криптографии/HSM);​
• обеспечивать воспроизводимость решений ИИ - по идентификатору проекта или клиента можно восстановить, какая версия модели и какие признаки использовались при скоринге (важно для споров с клиентом и взаимодействия с регулятором).

6. Организация разработки

• Отдельная команда по данным и машинному обучению ведёт репозиторий с пайплайнами: загрузка данных, построение признаков, обучение, ввод в эксплуатацию.
• Непрерывная интеграция и поставка (CI/CD) для моделей:
  commit → тесты → обучение → оценка → ручное одобрение → выкладка в тестовую среду → A/B‑тест → перевод в промышленную среду.
• Ведётся документация и «каталог моделей»: какая модель за что отвечает, какие у неё входы и выходы, ограничения и соглашения по уровню сервиса (SLA).

Такой контур даёт ИИ НЕКСУС предсказуемость, контролируемость.