Когда мы сокращали время кредитного решения на 35%, самым дорогим оказалось не ускорение, а то, что нельзя было выбросить.

Автоматическая цепочка «данные → скоринг → правила → решение» в кредитовании работает давно, задолго до моды на агентов. Новизна не в том, что решение принимает машина. Новизна в том, что регулятор или суд могут спросить «почему этому клиенту одобрили, а тому отказали» спустя год-два — когда модель уже трижды переобучена, отсечки переставлены, а человек, который их менял, работает в другом месте.

Поэтому конвейер решения обязан оставлять след. Минимум, без которого разговор с проверкой не состоится: — версия модели и набор правил, действовавшие в момент решения; — снимок входных данных: не «запросили БКИ», а что именно пришло; — кто, когда и на каком основании менял отсечку.

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

Что сработало у нас: журнал встроен в сам конвейер, а не собирается постфактум для отчётности. Каждый шаг решения пишет своё состояние по пути, ускорение ищем в параллельных запросах к источникам и в кэше данных, а не в отказе от следа. Итог — минус 35% ко времени решения при полной воспроизводимости любой заявки.

Для банков задача та же, только острее: чем больше ML в андеррайтинге, тем чаще вопрос «объясните решение» приходит не от клиента, а от надзора. Скорость и прослеживаемость не конфликтуют — конфликтует лень проектировать журнал с первого дня.

А у вас решение по заявке двухлетней давности можно воспроизвести за час — или это отдельный проект?