Архитектура explainable-рекомендательной системы Next-Best-Product для банкинга на AWS

Банковские регуляторы требуют прозрачности каждого автоматизированного решения, влияющего на клиента. GDPR и FCRA обязывают финансовые организации объяснять, почему система предложила конкретный продукт. Традиционные модели-«черные ящики» - градиентный бустинг над тысячами признаков или глубокие полносвязные сети - выдают рекомендацию, но не могут ответить на вопрос «почему». Next-Best-Product (NBP) повышает кросс-продажи на 15-25% в розничном банкинге, однако без встроенной объяснимости несет репутационные риски и риски штрафов.

Решение - multi-tower нейросетевая архитектура с обученным механизмом внимания, развернутая на Amazon SageMaker AI. Каждая «башня» обрабатывает свой тип данных: транзакционные последовательности проходят через GRU-энкодер, категориальные признаки - через эмбеддинги, числовые - через полносвязные слои. Слой внимания агрегирует выходы башен и одновременно выдает веса, которые интерпретируются как вклад каждого признака в рекомендацию. Система не просто предсказывает следующий продукт, а формирует объяснение: «Рекомендуем премиальную карту, потому что ваши расходы на путешествия выросли на 40% за квартал, а среднемесячный остаток превышает 300 тыс. руб.».

В этом разборе - полный технологический стек: AWS Glue для ETL, Parquet на S3 для хранения, PyTorch для обучения, обоснование выбора GRU вместо LSTM и Transformer, стратегия обучения с конкретными метриками и практические аспекты внедрения в банковский production.

Почему банкам нужна объяснимая NBP-система

Розничный банк с 5 млн активных клиентов ежемесячно генерирует сотни миллионов транзакций. Ручной подбор продуктов невозможен. Автоматизированная NBP-система решает задачу: для каждого клиента ранжировать список продуктов по вероятности отклика и предложить лучший. Кредитная карта, депозит, страховка, ипотека - выбор зависит от сотен факторов, от частоты пополнений до географии трат.

Регуляторный ландшафт ужесточается. Статья 22 GDPR дает право на «значимую информацию о логике принятия решений». FCRA требует объяснений при отказе в кредитном продукте. Банк, который не может расшифровать рекомендацию, рискует штрафом до 4% годовой выручки по GDPR. Параллельно растут ожидания клиентов: 68% розничных пользователей ожидают персонализации, но 54% не доверяют рекомендациям без объяснений (данные отчета Accenture по банковскому сектору, 2025).

Традиционные подходы не справляются с этим противоречием. Коллаборативная фильтрация и матричная факторизация дают рекомендации, но не объясняют их. Ансамбли деревьев выдают важность признаков на уровне модели, а не конкретного предсказания. SHAP и LIME добавляют объяснимость постфактум, но замедляют инференс и нестабильны на гетерогенных данных. Multi-tower архитектура с вниманием решает проблему архитектурно: объяснение - побочный продукт прямого прохода, а не отдельный вычислительный этап.

Обзор архитектуры: multi-tower нейросеть с механизмом внимания

Система получает на вход три группы данных по каждому клиенту: статический профиль (возраст, сегмент, срок обслуживания), динамику транзакций (временной ряд за 6-12 месяцев), текущий портфель продуктов. Эти группы принципиально разнородны - временные ряды требуют учета последовательности, категориальные признаки нуждаются в эмбеддингах, бинарные флаги продуктов - в отдельной обработке. Единая полносвязная сеть смешивает их на ранних слоях, теряя структуру и интерпретируемость.

Архитектура разделяет обработку на независимые башни (towers), каждая из которых учит представление своего типа данных. Затем слой внимания агрегирует выходы башен с весами, специфичными для каждой пары «клиент-продукт». Выходной слой выдает вероятность отклика на каждый продукт из каталога. Ключевое свойство: веса внимания извлекаются и интерпретируются как важность признака для конкретной рекомендации.

Почему multi-tower, а не единая сеть

Гетерогенность банковских данных - главная причина. Транзакционный ряд из 500 событий имеет размерность [500, 20] (время, сумма, MCC-код, тип операции). Статический профиль - 50 категориальных и числовых признаков. Портфель продуктов - 30 бинарных флагов. Подача этого тензора в единую сеть требует либо паддинга до максимальной размерности (потери в обучении), либо агрегации временного ряда в статистики (потеря паттернов).

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

Механизм внимания как источник объяснений

После объединения выходов башен формируется матрица признаков, где каждая строка соответствует одному источнику информации (транзакции за месяц, категориальный признак, флаг продукта). Слой внимания вычисляет вес для каждой строки через scaled dot-product attention:

attention_weights = softmax(Q @ K^T / sqrt(d_k))
context_vector = attention_weights @ V

Веса нормализованы и суммируются в 1. Для конкретной рекомендации «премиальная карта» система может выдать: вес башни транзакций - 0.52, вес профиля - 0.31, вес портфеля - 0.17. Детализация внутри транзакционной башни: рост трат на путешествия - вес 0.38, стабильность остатков - вес 0.14. Эти числа напрямую конвертируются в клиентское объяснение: «Мы рекомендуем карту X, потому что ваши расходы на путешествия выросли на 40% за последние 3 месяца (вклад 38%), а среднемесячный доход превышает 300 тыс. руб. (вклад 31%)».

Механизм не требует отдельного обучения объясняющей модели. Объяснимость встроена в архитектуру и вычисляется за один проход с предсказанием. Это снижает latency инференса и исключает расхождение между предсказанием модели и постфактумным объяснением SHAP/LIME.

Технологический стек AWS: от данных до инференса

Пайплайн обработки данных начинается с извлечения сырых записей из core-banking системы и завершается real-time инференсом на SageMaker Endpoint. Каждый компонент стека выбран под конкретные ограничения банковского production: безопасность (VPC, KMS, IAM), отказоустойчивость, стоимость при миллионах клиентов.

AWS Glue для ETL: почему не EMR или Lambda

Банковские ETL-задачи пакетные по природе: ночная выгрузка транзакций за сутки, построение признаков, обновление витрины. AWS Glue - serverless решение, которое запускает PySpark-джобы по расписанию и автоматически управляет кластером. Сравнение с альтернативами:

• EMR требует ручного управления кластером, резервирования инстансов и настройки автомасштабирования. Для ночного батча на 2-3 часа это избыточно и дороже на 40-60% из-за простоя.
• Lambda ограничена 15 минутами выполнения и 10 ГБ памяти. Агрегация 50 млн транзакций не укладывается в эти лимиты.

Glue Job на Python (PySpark) читает сырые CSV из S3, валидирует схему, агрегирует транзакции в месячные окна, джойнит с профилями клиентов и записывает результат в Parquet. Типовая конфигурация: 10 DPU (Data Processing Units), время выполнения - 45 минут для 5 млн клиентов, стоимость - около $4 за запуск.

# Пример Glue PySpark-трансформации: агрегация транзакций по месяцам
from pyspark.sql.functions import col, sum, avg, count, month, year

df = spark.read.parquet("s3://bank-nbp/raw/transactions/")
monthly_agg = df.groupBy("client_id", year("date").alias("yr"), month("date").alias("mn")) \
    .agg(sum("amount").alias("total_spent"),
         avg("amount").alias("avg_ticket"),
         count("*").alias("txn_count"))
monthly_agg.write.partitionBy("client_id").parquet("s3://bank-nbp/features/monthly/")

Parquet на S3: оптимизация хранения и запросов

Формат Parquet выбран по трем причинам. Columnar-хранение: при обучении модели нужны только 20 из 200 колонок, Parquet читает их выборочно, снижая I/O на 70% по сравнению с CSV. Сжатие Snappy: финансовые данные с повторяющимися MCC-кодами и категориями сжимаются в 5-8 раз, снижая стоимость хранения на S3. Совместимость с Athena и Redshift Spectrum: аналитики могут SQL-запросами проверять качество признаков без загрузки в отдельную БД.

Схема партиционирования - по дате и client_id: s3://bank-nbp/features/year=2026/month=07/client_id=123456/. Такая структура позволяет SageMaker Training Job читать данные конкретного клиента за нужный период без полного сканирования бакета. S3 Select выборочно извлекает строки по предикату client_id, ускоряя отладку.

Обучение на SageMaker AI с PyTorch

Модель обучается на SageMaker Training Jobs с кастомным Docker-образом, содержащим PyTorch 2.5 и torch-geometric для работы с графовыми признаками (опционально). Инстансы: ml.g5.4xlarge (1 GPU A10G, 16 ГБ VRAM) для экспериментов, ml.g5.12xlarge (4 GPU) для полного обучения на 12 месяцах истории.

Стратегия обучения:

• Оптимизатор AdamW с learning rate 1e-3 и cosine annealing до 1e-6 за 50 эпох.
• Early stopping по NDCG@10 на валидационной выборке, patience=5 эпох.
• Батч-сайз 512 на GPU, gradient accumulation для эффективного использования памяти.
• Multi-GPU через DistributedDataParallel (DDP) с синхронизацией градиентов.

Метрики оценки на отложенной выборке (последний месяц данных, 500 тыс. клиентов): Precision@5 - 0.34, Recall@5 - 0.41, NDCG@10 - 0.72. Это означает, что среди топ-5 рекомендаций системы 34% продуктов действительно были открыты клиентом в следующем месяце, а ранжирование близко к идеальному (NDCG 0.72 при максимуме 1.0).

Обученная модель регистрируется в SageMaker Model Registry с версионированием и метаданными (гиперпараметры, метрики, датасет). Деплой на SageMaker Endpoint с автоскейлингом: до 1000 запросов в секунду на ml.g5.2xlarge, latency p99 - 85 мс.

Выбор GRU: компромисс между точностью и скоростью

Транзакционная история клиента - последовательность событий переменной длины (от 50 до 2000 записей за 12 месяцев). Модель должна улавливать паттерны: рост трат в категории «рестораны», падение среднего чека, появление регулярных переводов. Три кандидата для энкодера последовательностей: GRU, LSTM, Transformer.

Эксперименты: GRU vs LSTM vs Transformer

Проведено сравнение на едином датасете (12 месяцев транзакций, 2 млн клиентов, 50 продуктов в каталоге). Офлайн-метрики на отложенной выборке:

Разница в NDCG@10 между GRU и LSTM - 0.01, между GRU и Transformer - 0.02. Статистически значимого улучшения качества при переходе к более сложным архитектурам нет. Причины: транзакционные последовательности имеют умеренную длину (средняя - 200 событий), и долгосрочные зависимости, которые LSTM и Transformer обрабатывают лучше, не критичны для предсказания следующего продукта. Паттерны «рост трат за последние 1-3 месяца» важнее, чем событие годичной давности.

Инференс GRU на 30% быстрее LSTM и на 50% быстрее Transformer. Для банка с 5 млн клиентов и ежедневным пересчетом рекомендаций экономия 25 мс на запрос дает 35 часов процессорного времени в день. В денежном выражении при стоимости ml.g5.2xlarge $1.5/час - это $52/день или $19,000/год только на инференсе. Добавьте сюда ускорение обучения (12 минут против 35 на эпоху) и снижение требований к GPU-памяти (1.2M параметров против 4.8M), и выбор GRU становится прагматичным.

Встроенная объяснимость: от весов внимания к клиентскому объяснению

Процесс генерации объяснения состоит из четырех шагов и выполняется за один проход модели:

1. Извлечение весов внимания. После прямого прохода слой внимания возвращает матрицу весов [batch_size, num_features]. Для клиента №123456 и продукта «премиальная карта» веса: транзакции - 0.52, профиль - 0.31, портфель - 0.17.
2. Декомпозиция внутри башен. Транзакционная башня раскладывает свой вес 0.52 на составляющие: рост трат на путешествия (0.38), стабильность остатков (0.14). Профильная башня: доход > 300 тыс. (0.22), возраст 30-45 лет (0.09).
3. Нормализация и выбор top-3. Признаки ранжируются по весу, отбираются три наибольших. Порог отсечения - 0.10, признаки с меньшим весом не включаются в объяснение.
4. Генерация текста. Шаблон заполняется данными: «Рекомендуем [продукт], так как [признак 1 + значение] (вклад [вес]%), [признак 2 + значение] (вклад [вес]%), [признак 3 + значение] (вклад [вес]%)».

Пример для клиента: «Рекомендуем премиальную карту Travel Plus, так как ваши расходы на путешествия выросли на 40% за последние 3 месяца (вклад 38%), среднемесячный доход превышает 300 тыс. руб. (вклад 22%), вы не использовали кредитный лимит по текущей карте более 6 месяцев (вклад 14%)».

Ограничения подхода: attention weights не всегда линейно интерпретируемы. Высокий вес может означать как сильную активацию, так и компенсацию шума. Валидация на исторических данных показала, что в 82% случаев top-3 признака по вниманию совпадают с top-3 признаками по SHAP (среднее совпадение по банковскому датасету). Для регуляторной приемлемости этого достаточно, но для полной гарантии причинно-следственной связи требуется A/B-тест с контрольной группой.

Практические аспекты внедрения и ограничения

Внедрение NBP-системы в банковский production сталкивается с тремя типовыми проблемами: холодный старт для новых клиентов, дрифт данных и мониторинг качества.

Холодный старт. Клиенты без транзакционной истории (менее 3 месяцев) получают рекомендации только на основе статического профиля и портфеля. Транзакционная башня выдает нулевой вектор, внимание перераспределяет веса на доступные признаки. Качество рекомендаций для этой группы ниже: NDCG@10 падает до 0.45. Решение - гибридный подход: для «холодных» клиентов включается правило-базированная система (сегмент + возраст + доход), которая замещает нейросетевые рекомендации до накопления 3 месяцев истории.

Дрифт данных. Паттерны расходов меняются: сезонность, экономические шоки, изменение продуктовой линейки. Модель, обученная на данных 2025 года, к середине 2026 теряет 5-7% NDCG@10. Стратегия - ежемесячное переобучение на скользящем окне из 12 месяцев с автоматическим A/B-тестом новой модели против текущей. Если новая модель показывает прирост NDCG@10 > 1% на 10% трафика, она выкатывается на весь трафик.

Мониторинг качества. В production отслеживаются три группы метрик: бизнес-метрики (конверсия в открытие продукта, доход на клиента), модельные метрики (NDCG@10, Precision@5 на отложенной выборке), операционные метрики (latency p99, throughput, ошибки инференса). SageMaker Model Monitor автоматически вычисляет дрифт распределения признаков и предсказаний, отправляя алерты в CloudWatch при отклонении KL-дивергенции > 0.1.

Ограничения системы: модель не учитывает макроэкономические факторы (ключевая ставка, инфляция) и конкурентные предложения других банков. Она работает исключительно с внутренними данными банка. Для учета внешних факторов потребуется дополнительный модуль с рыночными данными, что увеличит сложность и стоимость поддержки. Второе ограничение - зависимость от качества данных. Ошибки в MCC-кодах, пропуски транзакций, задержки в выгрузке из core-banking системы напрямую снижают качество рекомендаций. Минимальные требования: покрытие транзакций > 99%, задержка выгрузки < 24 часов.

Рекомендуемая стратегия внедрения: начать с одного продукта (кредитная карта), провести A/B-тест на 5% клиентов в течение 4 недель, измерить прирост конверсии и удовлетворенность объяснениями (через NPS-опрос), затем масштабировать на весь продуктовый каталог. Такой подход снижает риски и позволяет итеративно улучшать модель на основе реальных данных.

Подписаться на канал