Почему проверять гипотезы страшно, а не проверять — ещё страшнее

«А что если … ?» — пожалуй, самый частый вопрос на уме у риск-аналитика.  Его хлеб — строить и проверять гипотезы, например: 

• А что если мы добавим в модель частоту смены адреса? Станет ли точнее наш прогноз по риску дефолта у стартапов?

• А что если учитывать текучку кадров у клиента? Сможем ли мы точнее предсказывать кассовые разрывы?

• А что если мы поднимем лимит по овердрафту у клиентов с идеальной платежной дисциплиной? Как это скажется на их лояльности вдолгую?

Привет, Хабр. В этой статье я хочу поговорить о том, как аналитики одной автолизинговой компании (далее для удобства — «ААА») наладили у себя конвейер быстрой проверки гипотез на low-code платформе для аналитики (и заодно перестали дергать своих разработчиков на мелкие изменения логики и правил).

Про гипотезы

Для начала договоримся о терминах — что такое «гипотезы» в таком бизнесе как лизинг автомобилей? Да что угодно. Ими могут быть совершенно разные по своим масштабам вещи, например: 

• А что если увеличить допустимую сумму мелких налоговых штрафов с 10 до 50 тысяч рублей? Те, кто не заплатил за парковку, всё равно платят лизинг исправно.

• А что если учитывать не только возраст компании, но и смену директора за последние два года? Если сменили трижды — возможно, стоит попросить поручителя.

• А что если полностью отказаться от жёстких стоп-факторов и перейти к взвешенной системе риска, где каждая просрочка лишь увеличивает ставку? Тогда рынок расширится, а потери останутся теми же.

Каждая гипотеза — это новый набор правил или изменение существующего. В «ААА» на данный момент таких бизнес-правил уже стало больше 250, хотя изначально, когда аналитики «ААА» еще осторожничали, правил было около сотни. И все эти правила раньше были гипотезами. Их нужно не только придумать, но и сформулировать, объяснить исполнителям, потом проверить на реальных данных, а потом внедрить в продакшен.

Почему проверять гипотезы по-старинке — страшнее переезда?

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

Логично? Вполне. 

Тогда рождается гипотеза, сформулируем её примерно так: «А что если добавить проверку на просрочку 90+ дней? Если такая просрочка выявляется — сделка автоматически уходит к экспертам на ручной разбор. Снизится ли тогда доля неплатежей?». 

Хорошая мысль. Её бы проверить. Для этого нужно:

1. Взять историю сделок — кто платил, кто нет.

2. Сходить во внешний сервис (например, бюро кредитных историй или Контур.Фокус, в случае «ААА») и вытащить оттуда данные по просрочкам.

3. Посчитать новый признак — «есть длинная просрочка или нет» (has_overdue_90_plus).

4. Прогнать старые заявки через эту новую логику и посмотреть: изменилось бы решение? Стало бы лучше?

5. Если да — внедрить правило в боевой конвейер.

Вроде бы типовая инженерная задача. Есть одно «но» — в «ААА» вся эта механика была зашита в CRM. А CRM, как известно, штука для ведения клиентов: заноси контакты, веди сделки, не забывай звонить. Это ни разу не движок для бизнес‑логики. И уж точно не продукт для проведения экспериментов.

Соответственно, чтобы добавить одно‑единственное новое правило, аналитик писал задачу разработчикам (см. рис. 1). Те брали её в работу, и через N-ное число недель (возможно и дней) выдавали результат. Потом аналитик тестировал, находил ошибку — разработчики исправляли. Ещё N-ый отрезок времени ожидания. Круг замыкался и простая правка «сделай порог не 10 тысяч, а 50» растягивалась на, скажем, полмесяца. Если же требовалось реализовать что-то посложнее — например, линейку правил для грузовиков — там и вовсе уходило до трёх месяцев.

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

Какой должна быть новая система?

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

Декомпозиция этой идеи привела к трем критериям (рис. 2) для системы проверки гипотез:

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

2. Гибкость. Возможность тестировать новые сценарии, менять настройки и добавлять источники данных без оглядки на legacy-код с табличкой «не трожь, а то всё сломается». Бизнес-правила должны стать как сменные картриджи в принтере: старый вынул, новый вставил. И неважно, что внутри — простая формула или нейросеть.

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

Писать с нуля систему — не вариант, дорого; покупать что-то тяжелое типа BRMS (Business Rule Management System) — значит, снова зависеть от программистов. На те же грабли. Не вариант. Так в «ААА» и пришли к тому, что наиболее близкий класс решений — low-code платформы. В таких платформах, помимо прочего бывают: 

1. Визуальные конструкторы, которые еще больше могут упростить жизнь аналитику (есть схожие черты с Excel, к которому аналитик обычно привычен). 

2. Гибкие возможности интеграции, чтобы подключать любые источники данных (API, СУБД). В некоторых платформах есть даже возможность использовать интеграции как кубики. При таком подходе аналитик может визуально, мышкой составлять эти кубики в нужные цепочки и получать преобразования данных из произвольного формата А в произвольный формат Б.

3. Модульность. Всю логику можно разбить на независимые подмодели. Работает, как конструктор LEGO: можно изменять один «кубик» (им может быть не только интеграция), не опасаясь, что вся конструкция рассыпется. 

О том, как подобная схема работает изнутри — ниже.

Как это построили в «ААА»: устройство конвейера для гипотез

В описываемом мною примере схема получилась простая (рис. 3): 

Расшифрую по шагам.  

Шаг 1. 

CRM‑система «ААА», которая принимает заявку от консультанта, собирает все данные (кто берёт, что берёт, на каких условиях) и упаковывает их в JSON — он старый, добрый, простой и предсказуемый. В JSON-объект складывается всё: и контрагенты, и автомобили, и история платежей — всё, что нужно для принятия решения.

Шаг 2. 

CRM отправляет JSON в очередь RabbitMQ (не напрямую в Платформу, та может быть занята в момент обращения).

Шаг 3. 

Платформа по мере возможностей забирает сообщение из очереди, разбирает JSON и прогоняет его через бизнес-правила (на момент описания кейса их было более 250). На выходе формируется JSON-ответ с решением (в данном случае: «одобрить», «отказать», «отправить на ручную проверку»), плюс список задач или рекомендаций для консультанта («проверить документы», «запросить поручительство», «уточнить сумму залога»).

Шаг 4. 

Платформа передает сформированный ответ специальной утилите, а та кладет его в очередь ответов в RabbitMQ.

Шаг 5. 

CRM забирает ответ, показывает его консультанту, консультант дальше уже работает по ситуации: говорит клиенту «да», «нет» или «подождите, мы проверим». 

Теперь пара слов о том, почему этот способ оказался удобным . Тут три простых соображения.

1. Асинхронность. Тут вроде бы все понятно, каждый компонент системы работает в своем темпе, данные не теряются.

2. Стандартизация. Все запросы и ответы имеют строгую JSON‑схему. Это значит, что если аналитик захочет добавить в заявку новое поле — например, «средний возраст автопарка» — ему не придется переписывать всю интеграцию. Достаточно расширить схему, и Платформа сама разберёт обновлённый JSON. 

3. Скорость. Среднее время обработки одного сообщения — меньше пяти секунд.

Теперь расскажу о том, что происходит внутри Платформы после того, как она забрала JSON из очереди.

4. Что у Платформы «под капотом»?

Сначала платформа парсит JSON и превращает его в древовидную структуру данных.  Для тех, кто привык к базам данных, процесс похож на денормализацию вложенной структуры в плоские таблицы. Дальше эта древовидная структура попадает в большой «блок обработки данных». Его можно умозрительно представить как «стеллаж с кубиками» (я про кубики писал выше). В каждом кубике — своя независимая подмодель, например: 

• ящичек «Правила проверки контрагентов по внешним сервисам» (например, «Контур.Фокус»), 

• ящичек «Расчёт финансовых метрик» (долговая нагрузка, налоги, выручка), 

• ящичек «Проверка по чёрным спискам», 

• ящичек «Внутренний скоринг». 

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

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

• Если всё зелено и сумма небольшая — авторешение «одобрить».

• Если есть красный стоп-фактор (например, компания в реестре недобросовестных поставщиков) — авторешение «отказать».

• Если что-то жёлтое (порог превышен, но не критично) — сделка уходит в «серую зону».

Про «серую» зону скажу отдельно. Для нее предусмотрен отдельный блок — выставление задач. Здесь Платформа, согласно заложенным правилам (в системе их около 70), формирует список задач для экспертных подразделений, которые должны пересмотреть заявку, например, для «Службы безопасности» или «Отдела залогов». Эти задачи упаковываются в JSON и уходят обратно в CRM, где консультант «ААА» уже распределяет их по соответствующим исполнителям. 

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

Вживую весь процесс принятия решения работает примерно так. Открываем какой-нибудь узел в середине конвейера — там, скажем, имеется таблица с промежуточными данными. Щёлкнул по правилу — увидел, сколько входных параметров зашло в него, на скольких сработало true, на скольких — false. Соответственно, всегда пройти по шагам и понять, почему система выдала именно такое решение (в отличие от решений ИИ).

И, удобство low-code платформ как раз в том, что подобную логику аналитики могут собирать сами, без разработчиков — то есть проверки получаются быстрыми и дешевыми.

Далее расскажу о том, как конкретно можно корректировать правило.  

5. Почему эксперименты вдруг стали такими быстрыми и дешевыми?

Допустим, аналитик «ААА» заметил, что клиенты с мелкими налоговыми штрафами платят исправно, и решил проверить гипотезу: поднять порог для отказа с 10 до 50 тысяч рублей.

Аналитик открывает нужный «кубик» (рис. 5) — подмодель «Проверка финансовой дисциплины», — находит узел с условием: 

задолженность_по_налогам > 10000

Меняет 10000 на 50000. Всё. 

То есть он меняет логику только внутри одного «ящичка». Все остальные части системы этого даже не замечают. Получается довольно безопасно, типа как сменить лампочку в комнате —  для этого не нужно отключать электричество во всем доме.

Возможно, внимательный читатель из разработчиков возразит: «Стоп! А что там с тестированием? Вдруг новое правило даст сбой на каких-то пограничных случаях?».

Для этого на платформах бывает режим отладки — можно взять любую заявку (или десяток таковых) и прогнать их через изменённую подмодель, в обход «боевого» контура. Опять же, это может делать и сам аналитик — прямо из визуального интерфейса — и там он может увидеть промежуточные данные на каждом узле — сколько заявок попало в одну ветку, сколько в другую, какие значения приняли флаги.

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

6. Заключение: ключевые выводы из кейса

Опыт компании «ААА» показывает, что внедрение low-code платформы способно кардинально изменить подход к проверке гипотез, превратив его из долгого и рискованного процесса в быстрый и практически рутинный. Если вы для себя рассматриваете подобный путь, вот несколько ключевых выводов из этого кейса, которые могут пригодиться:

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

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

3. Снижайте цену ошибки. Когда проверка гипотезы занимает 15 минут времени аналитика, а не недели разработки, вы перестаете бояться ошибаться. И тогда из десяти гипотез, девять из которых могут оказаться неудачными, одна обязательно «выстрелит» и с лихвой окупит все эксперименты.

4. Тестируйте на живом трафике безопасно. Подход «Чемпион/Челленджер» (рис. 6). — отличный инструмент для этой цели. Основная масса заявок (например, 95%) идет по старой, проверенной модели («Чемпион»), а небольшая часть (5%) — по новой («Челленджер»). Сравнив результаты, можно принять взвешенное решение о том, чтобы сделать «Челленджера» новым «Чемпионом».

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

Всего хорошего, и пусть ваши гипотезы взлетают.

С уважением,
Алексей Арустамов,
разработчик и директор одной low-code аналитической платформы.