ИИ-скоринг

Что считает модель

Скоринг на машинном обучении считает вероятность нужного исхода по каждой заявке: вернёт ли клиент рассрочку, дойдёт ли лид до оплаты, сорвётся ли сделка, уйдёт ли абонент к конкуренту. Модель учится на ваших исторических данных - кто платил, кто пропал, кто жаловался - и выдаёт балл от 0 до 100 ещё до того, как менеджер взял трубку. Этот балл подставляется в amoCRM, Bitrix24 или 1С, и отдел работает по приоритету, а не по очереди поступления.

Ручные правила вроде «возраст 25-45 и доход выше 300 000 ₸» ловят очевидное и пропускают остальное. ML находит связи, которые человек не сведёт в голове: например, что заявки с корпоративной почты и второй покупкой за полгода платят на 40% стабильнее, а ночные регистрации с одноразовых номеров - почти всегда мусор. Под капотом обычно градиентный бустинг (XGBoost, CatBoost, LightGBM) или логистическая регрессия для задач, где важна прозрачность каждого фактора.

Скоринг закрывает четыре типовые боли. Первая - менеджеры тратят одинаковое время на горячих и на безнадёжных. Вторая - рассрочки и постоплату выдают по интуиции, а потом списывают убытки. Третья - фрод и мусорные заявки забивают воронку. Четвёртая - отток клиентов замечают постфактум, когда удерживать уже поздно. Внедрение ИИ-скоринга переводит эти решения с «на глаз» на воспроизводимый балл, который можно проверить на отложенной выборке до того, как доверить ему живой поток.

Где применяют

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

Когда скоринг окупится

Берите скоринг, если у вас есть хотя бы три пункта из списка - иначе модель не на чем учить или нечего ускорять:

• ☑ От 300-500 заявок или сделок в месяц - на меньшем объёме статистики мало.
• ☑ Накоплена история за 6-12 месяцев с понятным результатом: оплатил / не оплатил, вернул / просрочил.
• ☑ Заявок больше, чем менеджеры успевают качественно обработать.
• ☑ Цена ошибки заметна: невозврат рассрочки, слитый рекламный бюджет, отгрузка неплатёжеспособному клиенту.
• ☑ Решение о заявке принимается часто и по похожей логике.
• ☑ Данные лежат в CRM, 1С или таблицах, а не только в голове у директора.
• ☑ Есть человек со стороны бизнеса, который объяснит логику сделок и поможет разметить исходы.
• ☑ Доля «плохих» исходов хотя бы 5-10% - если просрочка близка к нулю, модели не на чём учиться отличать риск.

Зеркальная честность: если у вас меньше 100 заявок в месяц, истории нет, каждая сделка уникальна (крупные тендеры, штучные проекты) или в CRM дубли и пустые поля - скоринг даст меньше, чем стоит. Сначала наводим порядок в данных, и часто это уже половина эффекта.

Как мы это внедряем

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

• Определяем цель в деньгах. Не «сделать ИИ», а «снизить просрочку по рассрочкам на N%» или «поднять конверсию горячих лидов». От этого зависит, что предсказываем и как меряем успех.
• Собираем признаки из ваших источников. История покупок и оплат из 1С, поведение в CRM, источник заявки, сумма, регион, тип оплаты, частота обращений. Часть признаков считаем сами - например, среднюю задержку платежа за полгода.
• Чистим данные. Убираем дубли, заполняем или помечаем пропуски, выравниваем статусы. Грязные данные дают грязный балл - этот шаг обычно самый трудоёмкий.
• Обучаем несколько моделей и сравниваем. Логистическую регрессию для прозрачности, бустинг для точности. Выбираем по метрикам на отложенной выборке, а не по красивым цифрам на обучении.
• Настраиваем порог отсечения под ваш риск-аппетит. Где автоодобрение, где ручная проверка, где отказ. Порог вы регулируете сами и потом меняете под сезон или новую стратегию.
• Добавляем объяснимость. К каждому баллу - список факторов, которые на него повлияли (через SHAP или веса модели). Менеджер видит не только число, но и почему оно такое.
• Встраиваем в процесс и обучаем команду. Балл приходит в карточку сделки, уведомления о рисках - в Telegram или WhatsApp. Без этого шага модель остаётся отчётом, который никто не открывает.

Термины без воды

Скоринговый балл

Число от 0 до 100: насколько вероятен нужный исход по конкретной заявке. Это не «хороший/плохой», а градиент, по которому вы расставляете приоритеты.

Признаки (фичи)

Данные, по которым модель решает: сумма, источник, история покупок, регион, тип оплаты, частота просрочек. Чем осмысленнее признаки, тем точнее балл - половина работы дата-сайентиста именно здесь.

Обучающая выборка

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

Точность (precision)

Какая доля заявок, помеченных «хорошими», действительно оказалась хорошей. Важна там, где дорого ошибиться в одобрении.

Полнота (recall)

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

Порог отсечения

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

Объяснимость (explainability)

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

Готовое или своя модель

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

Данные и интеграции в РК

Скоринг живёт внутри ваших систем, а не отдельным сайтом, в который никто не заходит. Балл приходит туда, где работает отдел: в карточку сделки amoCRM или Bitrix24, в 1С, в лёгкий веб-интерфейс оператора. Сортируем воронку по приоритету, а уведомления о горячих или рискованных заявках шлём в WhatsApp и Telegram менеджеру или руководителю.

Источники данных под Казахстан: продажи, оплаты и долги из 1С; платежи и рассрочки, связанные с Kaspi и Halyk (Homebank); заявки с сайта, форм и маркетплейса через API. Для интернет-магазина на Kaspi это особенно живая тема - Kaspi-рассрочка и Red формируют поток постоплатных заявок, и здесь скоринг помогает решать, кому отгружать с риском, а кого просить о предоплате. Платёжную дисциплину и поведение клиента собираем из доступных вам выгрузок, не пытаясь подменить решение банка или кредитного бюро.

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

Ориентиры цен и сроков

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

Где обычно спотыкаются

Типичные ошибки внедрения скоринга мы видели достаточно, чтобы обходить их заранее. Утечка целевой переменной - когда в признаки случайно попадает то, что известно только после исхода (например, дата закрытия долга при прогнозе просрочки). Модель показывает фантастическую точность на обучении и разваливается на боевом потоке. Лечится аккуратным разделением данных по времени и проверкой каждого признака на «а знали бы мы это в момент заявки».

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

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

Логика на примере

Чтобы это не звучало абстрактно - две обобщённые ситуации из практики внедрения ИИ для бизнеса в РК. Интернет-магазин на Kaspi выдаёт постоплату и рассрочку и регулярно списывает невозвраты. Берём историю заказов за год: суммы, категории, повторность покупок, задержки платежей, регион доставки. Обучаем модель риска, ставим порог так, что около 70% заявок проходят автоодобрение, 20% уходят на ручную проверку оператору, 10% получают предоплату вместо рассрочки. На пилоте на отложенной выборке доля плохих долгов падает заметно, при этом общее одобрение не проседает - модель режет именно рискованных, а не всех подряд.

Второй пример - микрофинансовая организация с потоком заявок и ручным андеррайтингом. Здесь критична полнота: пропустить плохого заёмщика дороже, чем перепроверить хорошего. Строим модель кредитного скоринга, к каждому решению прикладываем факторы (через SHAP), чтобы андеррайтер видел причину и мог оспорить. Балл приходит в рабочую систему, уведомления о пограничных заявках - в Telegram. Эффект двойной: быстрее обрабатываются явно хорошие заявки, а спорные получают человеческое внимание вместо конвейерного «нет». Названий компаний не приводим намеренно - логика воспроизводима, конкретные цифры всегда считаются на ваших данных.

Этапы работы

Цены и характеристики

Ответы на частые вопросы