Архитектура банковского RecSys в 2026: что реально работает и как собирать систему с нуля

Короткий ответ: банковский RecSys в 2026 году стоит строить как каскад из событийного pipeline, feature store, генератора кандидатов, ranking-модели и policy-слоя, который проверяет ограничения перед показом. Для клиентских последовательностей добавляют sequence backbone, для поиска офферов комбинируют OpenSearch, точные фильтры и векторную близость.

Архитектура банковских рекомендаций заметно отличается от решений для e-commerce и видеоплатформ. Целевые действия здесь редкие, цена ошибки выше, часть признаков нельзя использовать без проверки правомерности, а клиенту часто нужно объяснить, почему он увидел конкретный оффер. Поэтому универсальная схема строится вокруг качества событий, контроля eligibility, калибровки вероятностей и аудируемости.

Практичный порядок сборки выглядит так: аудит данных, baseline на правилах, единый event pipeline, генерация кандидатов, ранжирование, затем A/B-тест с заранее заданными метриками и сроком наблюдения. Нейросеть и эмбеддинги добавляют после того, как простая версия дает надежную точку сравнения.

Почему банковский RecSys - это не e-commerce: ключевые отличия

Банк рекомендует финансовый продукт в ситуации, где у клиента есть юридические, рискованные и временные ограничения. Оффер может подходить по интересу, но не проходить проверку доступности. В e-commerce часть таких ограничений тоже встречается, однако банковский RecSys должен учитывать их на каждом шаге, включая генерацию кандидатов и финальный serving.

Параметр	Банковский RecSys	E-commerce	Видеоплатформы
Целевое действие	Заявка, открытие вклада, выпуск карты, активация сервиса	Просмотр товара, добавление в корзину, покупка	Клик, просмотр, досмотр, повторный запуск
Частота положительных событий	Часто низкая, особенно для сложных финансовых продуктов	Обычно выше на популярных категориях	Просмотры и клики происходят часто
Ограничения	Eligibility, регуляторные правила, лимиты, доступный канал коммуникации	Цена, остатки, доставка, регион	Возрастные, лицензионные и контентные ограничения
Цена ошибки	От раздражения клиента до финансового ущерба и нарушения правил	Потеря продажи или ухудшение пользовательского опыта	Снижение удержания и времени просмотра
Интерпретируемость	Нужны проверяемые причины показа и история решений	Чаще достаточно продуктовой аналитики	Главный акцент обычно на удержании и разнообразии

Редкие целевые события и их влияние на обучение

При условной конверсии в оффер 0,1% положительный пример приходится на 999 отрицательных. Модель, которая всегда отвечает «клиент не оформит продукт», получит 99,9% accuracy и окажется бесполезной. Поэтому accuracy нельзя делать главной метрикой.

Для обучения применяют взвешенную бинарную cross-entropy, focal loss или контролируемое сэмплирование отрицательных событий. При уменьшении числа negative-примеров нужно сохранить их распределение и учесть коэффициент сэмплирования при расчете вероятностей. Иначе ranking-модель будет выдавать слишком высокие оценки.

• AUC-PR лучше отражает качество при сильном дисбалансе классов, чем одна AUC-ROC.
• Recall@K показывает, попал ли подходящий оффер в набор кандидатов.
• NDCG@K учитывает порядок рекомендаций в верхней части списка.
• Expected calibration error помогает проверить, соответствует ли прогноз 0,2 вероятности примерно двум положительным событиям на тысячу показов.
• Conversion и доход на eligible-клиента связывают модель с бизнес-результатом, но требуют окна атрибуции.

Распределение данных стоит проверять отдельно для новых и активных клиентов, разных каналов и типов офферов. У модели может быть хороший общий AUC-PR и слабая работа с новым клиентом, у которого нет истории действий. Для cold start пригодятся признаки текущей сессии, разрешенный сегмент, контекст канала, популярность оффера в сопоставимой группе и контролируемая exploration-политика.

Регуляторные ограничения и интерпретируемость

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

SHAP и LIME помогают объяснить вклад признаков, но постфактум-объяснение не доказывает причинность решения. Практичный вариант строится в два слоя: модель считает score, а отдельный explanation-модуль переводит допустимые признаки в ограниченный набор reason codes. Например, причина может ссылаться на активность клиента в нужном канале или на соответствие продукта выбранному сегменту, если использование такого признака разрешено политикой данных.

• Сформируйте allowlist признаков и укажите владельца каждого поля.
• Отделите признаки, нужные для eligibility, от признаков, которые влияют на предпочтение.
• Удалите прямые и косвенные прокси чувствительных характеристик, если их использование запрещено.
• Храните audit log: клиентский контекст, список доступных офферов, score, позицию, policy и результат.
• Проверяйте объяснения на стабильность: одинаковые условия не должны порождать случайные причины.

Высокая стоимость ошибки меняет порог допуска. Оффер с небольшим прогнозом клика может оказаться хуже отсутствия рекомендации, если он создает лишнюю коммуникацию или приводит клиента на неподходящий продукт. Финальное решение поэтому принадлежит policy-слою, а ranking-модель отвечает за порядок уже допустимых кандидатов.

Классические компоненты RecSys, которые все еще нужны в 2026

Базовый конвейер сохраняет четыре блока: сбор событий, генерация кандидатов, ранжирование и serving. Их границы полезно поддерживать явными. Так проще заменить LightGBM на нейросеть, добавить векторный retrieval или отключить источник признаков без переписывания всей системы.

Сбор событий: от batch к real-time

Ежедневный batch подходит для медленно меняющихся признаков, например агрегатов за 30 дней. Он плохо реагирует на короткую сессию: клиент открыл страницу вклада, отказался от одного оффера и перешел в мобильное приложение. Потоковая обработка через Kafka и Flink позволяет обновлять контекст после каждого значимого события.

Требование exactly-once нужно трактовать аккуратно. Даже если отдельный процессор поддерживает такую семантику, внешняя система может повторно отправить сообщение. Поэтому каждое событие получает стабильный event_id, а запись признаков должна быть идемпотентной. Дубликат не должен удваивать счетчик открытий страницы или менять порядок последовательности.

• event_id и client_id, если идентификатор разрешено использовать в этом контуре;
• event_type, объект действия и канал;
• серверное время, клиентское время при наличии и признак задержки;
• версию схемы события и источник;
• признак показа, позицию в списке, policy и версию модели;
• последующий клик, начало заявки и целевое событие с отдельным временем.

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

Генерация кандидатов: от правил к гибридному поиску

Генератор кандидатов уменьшает каталог до списка, который ranking-модель успевает обработать. На старте это может быть набор правил и популярные офферы внутри допустимого сегмента. Позже добавляются коллаборативная фильтрация, текстовый retrieval и ANN-поиск по эмбеддингам.

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

Качество этого слоя измеряют через Recall@K. Если ranking получает 200 кандидатов, но подходящий продукт попадает туда лишь в 60% случаев, улучшение финальной модели не решит проблему. В качестве стартовой конфигурации можно подать на ranking 100-500 офферов, а затем сократить список после измерения latency и recall.

Ранжирование: от логистической регрессии к градиентному бустингу и нейросетям

Ranking-модель получает клиента, оффер и контекст показа, после чего считает вероятность или полезность каждой пары. Логистическая регрессия остается хорошим baseline: ее легко обучать, калибровать и объяснять. Градиентный бустинг на табличных признаках обычно дает более гибкие взаимодействия при умеренной сложности serving.

Нейросеть с эмбеддингами нужна, когда в данных много категорий, последовательностей и семантических признаков. Она может учитывать близость клиентского и офферного представлений, но требует контроля дрейфа, версии энкодера и качества отрицательных примеров. Финальный ответ должен пройти policy-слой: частотные ограничения, diversity, приоритет коммуникационного канала и повторное применение eligibility.

Событийный пайплайн и sequence backbone: как готовить данные для моделей

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

Рабочая цепочка выглядит так: источники событий, CDC через Debezium при необходимости, Kafka, обработка в Flink, offline-хранилище для обучения, online feature store для serving, Redis для быстрых значений. Конкретный стек зависит от требований к задержке, объема данных и уже существующей платформы.

Feature store как единый источник признаков

Feature store разделяет online и offline контуры, сохраняя единое описание признака. В offline-части лежат исторические значения с временем их доступности. В online-части находятся свежие значения для инференса. Такое разделение помогает избежать training-serving skew, когда модель обучалась на одной логике расчета, а в production получает другую.

Feast и Tecton можно использовать как ориентиры для организации feature store. Redis подходит для online-значений с коротким путем чтения. Важнее названия продукта контроль временных срезов: при обучении признак должен отражать только то, что было известно на момент показа.

• Дайте каждому признаку имя, тип, TTL, источник и владельца.
• Версионируйте код расчета и схему данных.
• Стройте point-in-time join, чтобы события из будущего не попадали в прошлое.
• Сравнивайте offline и online значения на одинаковом наборе клиентов.
• Храните пропуски как отдельное состояние, когда отсутствие значения несет смысл.

Для проектирования признакового контекста пригодится разбор context engineering для data scientist. В RecSys этот принцип означает явное описание состава, времени и источника контекста, а не передачу модели случайного набора полей.

Sequence backbone: представление клиентской истории

Sequence backbone превращает последовательность действий клиента в компактное представление, например вектор e_seq. На вход можно подавать тип события, категорию оффера, канал, временной интервал после предыдущего действия, сессионный контекст и агрегированные числовые значения, если их использование разрешено.

Минимальная схема выглядит так: каждый event token получает embedding, к нему добавляются временные и контекстные признаки, затем encoder строит итоговый вектор истории. В простом варианте используется агрегация последних событий. RNN подходит для коротких последовательностей и меньших вычислительных бюджетов, Transformer удобнее при длинной истории и сложных зависимостях, но требует контроля длины окна и latency.

Для первой версии можно ограничить историю последними 50 или 100 событиями как инженерный параметр, а затем подобрать окно по offline-метрикам и времени ответа. Универсального оптимального размера нет. Длинная история может добавить шум, а короткая потеряет устойчивые интересы клиента.

Обучение sequence backbone требует временного разреза. События после момента показа нельзя использовать при формировании входа. Положительный пример связывают с будущим действием в заданном окне, отрицательный пример выбирают среди офферов, которые были доступны и показаны либо могли быть показаны по policy.

PyTorch и TensorFlow закрывают базовые задачи подготовки последовательностей, маскирования и обучения encoder. В production отдельно версионируйте tokenizer событий, таблицы embedding и саму модель. Замена кодировки категории без пересчета индекса офферов создаст трудноуловимую ошибку.

Гибридный отбор кандидатов: OpenSearch + векторный поиск

Одного векторного поиска недостаточно. Эмбеддинг может уловить семантическую близость, но не проверит жесткое ограничение, точное совпадение кода продукта или актуальность оффера. OpenSearch позволяет собрать несколько retrieval-веток: фильтры, текстовый поиск и k-NN по вектору.

Индексация офферов и клиентских профилей

Индекс офферов должен хранить стабильный идентификатор, текстовое описание, категорию, доступные каналы, признаки eligibility, сроки действия, версию данных и embedding. Набор полей определяется каталогом банка. Не следует помещать в индекс необработанные персональные данные, если для retrieval достаточно обезличенного профиля или агрегатов.

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

Проверяйте similarity на отложенной выборке. Косинусная близость, dot product и L2 distance дают разные шкалы, поэтому пороги нельзя переносить между индексами без повторной калибровки.

Комбинирование результатов: правила + текст + векторы

Поток запроса может выглядеть так:

1. filter: eligibility, channel, status, time_window
2. text: match(offer_text, client_context)
3. vector: knn(profile_embedding, k=100)
4. merge: deduplicate by offer_id
5. rank: combine retrieval signals

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

Для объединения списков подходит Reciprocal Rank Fusion. Упрощенная формула выглядит так: score = sum(1 / (k + rank)), где rank - позиция оффера в отдельном списке, а k сглаживает влияние первых позиций. Взвешенное суммирование тоже допустимо, но перед ним нужно привести скоринги разных веток к сопоставимой шкале.

• Удаляйте дубликаты по offer_id, сохраняя признаки всех источников.
• Записывайте, какая ветка нашла кандидата.
• Отделяйте recall-метрики каждой ветки от итогового recall.
• Ограничивайте долю одного продукта и близких вариантов.
• Повторяйте eligibility после объединения, потому что данные могли измениться между чтением профиля и serving.

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

Ранжирование поверх табличных признаков и эмбеддингов

На вход финальному ranker поступает пара клиент-оффер и признаки показа. Обычно это табличные данные, embeddings, score от OpenSearch, позиция в исходном списке, свежесть события и признаки доступности канала.

Градиентный бустинг: проверенный базовый уровень

LightGBM и XGBoost подходят для первого серьезного ranker, потому что работают с нелинейными зависимостями, пропусками и смешанными типами признаков. Модель может использовать:

• частоту действий клиента в категории за несколько временных окон;
• время после последнего события;
• историю показов и повторов оффера;
• соответствие eligibility и канала;
• score текстового и векторного retrieval;
• cosine similarity между профилем клиента и оффером;
• агрегаты sequence backbone, например нормы, проекции и близость к embedding оффера.

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

SHAP для бустинга помогает увидеть вклад признаков на уровне отдельного решения. Это не заменяет проверку допустимости признака и не объясняет причинно-следственную связь. Для пользователя лучше формировать короткий reason code из заранее разрешенного набора.

Нейросети с эмбеддингами: когда нужно больше гибкости

Two-tower модель разделяет encoder клиента и encoder оффера. Их векторы сравниваются через dot product или cosine similarity, что удобно для предварительного retrieval. Для финального ranking нужны взаимодействия между контекстом, клиентом и конкретным оффером, поэтому здесь применяют MLP, DCN или DeepFM.

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

Гибридная схема может выглядеть так:

OpenSearch hybrid retrieval -> 200 candidates
GBDT ranker -> 20 candidates
neural reranker or policy layer -> final slate

Такой каскад оставляет бустинг контролируемым базовым уровнем, а нейросети дает узкую задачу, где дополнительная сложность оправдана. Переход к neural reranker стоит делать после сравнения с GBDT на временном holdout и проверки latency, calibration, explanation и стабильности по сегментам.

Смещение логов и коррекция по позиции: почему модель врет

Исторический лог показывает поведение клиентов под действием старой policy. Оффер в первой позиции получает больше внимания, популярный оффер чаще показывается, а редко тестируемый кандидат почти не имеет наблюдений. Модель может принять следствие старой выдачи за предпочтение клиента.

Здесь встречаются три смещения:

• Position bias: вероятность клика зависит от позиции, даже при одинаковом интересе к офферам.
• Selection bias: лог содержит результаты только для кандидатов, которых выбрала предыдущая policy.
• Survivorship bias: в данных сильнее представлены клиенты и офферы, которые уже прошли предыдущие фильтры.

Inverse Propensity Scoring (IPS) и его ограничения

IPS взвешивает наблюдение по обратной вероятности того, что действие попало клиенту в показ. Для простого случая запись можно обозначить так: L_IPS = (1/n) * sum((c_i * y_i) / p_i). Здесь y_i - результат, c_i - индикатор нужного наблюдения, а p_i - propensity, вероятность показа действия при заданном контексте.

Без оценки propensity IPS не исправляет смещение. Если p_i близка к нулю, вес становится большим и резко повышает дисперсию оценки. На практике вводят clipping, например ограничивают минимальную вероятность значением p_min, а чувствительность результата проверяют на нескольких порогах.

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

Контрфактуальная оценка: как понять, что было бы, если бы показали другой оффер

Контрфактуальная оценка пытается оценить результат policy, которая не совпадает с политикой в логе. Один из вариантов, doubly robust estimator, объединяет outcome-модель и propensity-модель:

V_DR = (1/n) * sum(m(x_i, pi(x_i)) + I(a_i = pi(x_i)) / p_i * (r_i - m(x_i, a_i)))

m прогнозирует результат для контекста и действия, pi выбирает новый оффер, r_i хранит наблюдаемый результат. Подход может быть устойчивее, когда одна из моделей задана хорошо, но он сохраняет требования к покрытию действий и качеству propensity. Если новая policy предлагает офферы, которых почти никогда не было в логе, исторические данные не дадут надежного ответа.

Для будущей оценки добавляют небольшую контролируемую exploration-долю. Логируйте полный slate, список eligible-кандидатов, policy, score каждого оффера, позицию, факт видимости, propensity, клик и целевое действие с временным окном. Эти поля превращают лог показа в данные для анализа, а не в набор случайных кликов.

A/B-тестирование с редкими событиями: как не ждать месяцами

Редкое событие требует расчета мощности до запуска эксперимента. При базовой конверсии 0,1% и относительном улучшении 20% простая оценка для двух пропорций дает примерно 430 тысяч показов на группу при уровне значимости 5% и мощности 80%. Это ориентир без учета кластеризации по клиенту, нескольких метрик, задержки конверсии и потерь данных.

При относительном улучшении 10% потребный объем становится значительно больше. Поэтому раннее решение по нескольким дням CTR может создать ложное ощущение успеха, если конечная конверсия еще не успела проявиться.

Выбор метрик: от кликов к бизнес-показателям

Метрики стоит разделить на три уровня:

• Основная: конверсия в целевой банковский продукт на eligible-клиента или доход на такого клиента.
• Прокси: CTR, переход к форме, глубина просмотра, начало заявки.
• Guardrails: ошибки eligibility, отказы от коммуникаций, жалобы, повторные показы и latency.

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

Рандомизацию лучше проводить на уровне клиента, чтобы один человек не попадал одновременно в control и treatment на разных показах. Зафиксируйте assignment, не меняйте группу после первого показа и заранее опишите правила исключения. При нескольких каналах нужно контролировать загрязнение эксперимента, когда разные policy влияют на одного клиента.

Байесовский подход к A/B-тестам

Байесовский тест оценивает posterior-распределение конверсии и вероятность того, что treatment превосходит control на заданную величину. Для расчетов подходят PyMC и Stan. Такой подход удобен при регулярном обновлении данных и заранее заданном правиле решения.

Байесовская модель не отменяет неопределенность и не делает маленькую выборку достаточной. При малом числе целевых событий posterior останется широким. Sequential testing тоже требует формального stopping rule, иначе многократный просмотр результатов повышает риск случайного решения.

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

Пошаговый план: собираем банковский RecSys с нуля

Этап 1: Аудит данных и определение целей

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

• Выберите один продукт и одно основное целевое событие.
• Зафиксируйте eligible-множество и причины исключения.
• Проверьте дубликаты, пропуски, временные зоны и задержки.
• Разделите события по времени, чтобы исключить утечку будущего.
• Согласуйте метрики: Recall@K, NDCG@K, AUC-PR, ECE и конечную конверсию.

Результат этапа, схема событий, таблица доступных признаков, definition of done для первой версии и список ограничений. Если целевой event не связывается с показом, обучение и эксперимент пока запускать рано.

Этап 2: Baseline без ML

Соберите rule-based выдачу для самых популярных офферов внутри сегмента и канала. Добавьте frequency cap, срок действия и повторную проверку eligibility. Baseline должен логировать тот же набор полей, что и будущая модель.

Сравнивайте сегментную популярность с глобальной популярностью. Новому клиенту можно показать безопасный fallback, но его результат нужно хранить отдельно, иначе cold-start данные смешаются с поведением активных пользователей.

Этап 3: Событийный пайплайн и feature store

Настройте прием событий через Kafka, обработку в Flink и запись агрегатов в offline-хранилище. Для CDC из операционных систем при необходимости используйте Debezium. Online-значения отдавайте через feature store и Redis, если это соответствует требованиям к задержке.

Каждый признак должен иметь версию и point-in-time корректную историю. Добавьте replay-процесс: возможность заново пропустить сохраненные события и сравнить результат с online-расчетом. Без replay трудно искать ошибки в дедупликации и временных окнах.

Этап 4: Генерация кандидатов

Оставьте правила обязательным фильтром, затем подключите несколько источников кандидатов: популярность, коллаборативную фильтрацию, текстовый поиск и OpenSearch k-NN. Векторный индекс стройте на версионированных embedding офферов и профилей.

Для каждой ветки посчитайте Recall@K, долю уникальных кандидатов, latency и частоту последующего целевого действия. После объединения используйте deduplication и Reciprocal Rank Fusion либо нормализованную сумму скорингов. Кандидаты, нарушающие жесткие правила, удаляются независимо от similarity.

Этап 5: Ранжирование и запуск A/B

Обучите GBDT на табличных признаках и retrieval-сигналах. Используйте временной holdout, проверку калибровки, SHAP для анализа и reason codes для объяснений. Нейросеть с эмбеддингами добавляйте после сравнения с этим baseline, если она улучшает нужные метрики при приемлемых latency и сложности сопровождения.

Следующий шаг, запуск контролируемого эксперимента:

1. Зафиксируйте treatment, control, assignment на уровне клиента и срок наблюдения.
2. Определите основную конверсию, прокси и guardrails до начала теста.
3. Сделайте расчет мощности с учетом базовой конверсии и ожидаемого эффекта.
4. Логируйте propensity, position, slate и все последующие статусы.
5. Проверяйте результат на сегментах, но не заменяйте общий критерий множеством случайных срезов.

Минимальная архитектура для первой версии: Kafka для событий, batch-процессинг для исторических агрегатов, Redis или online feature store для свежего контекста, OpenSearch для фильтров и гибридного retrieval, GBDT для ranking, отдельный policy-слой и клиентский A/B assignment. Sequence backbone и neural reranker добавляются после проверки качества данных и влияния baseline на бизнес-метрику.

Такой порядок дает измеримый путь развития. Каждая новая модель сравнивается с работающей системой, а ее score проходит через ограничения, аудит и эксперимент. Для банковского RecSys это полезнее громкого обещания универсальной нейросети: качество определяется полнотой событий, корректностью временных срезов и тем, насколько честно система измеряет результат.

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