Препринт Jize Li (arXiv, июль 2026, принят на AIIIP 2026) задал неудобный вопрос: действительно ли ML-модель помогает менеджеру выбрать, какие отгрузки проверить первыми — или достаточно просто отсортировать список по стоимости? Ответ на трёх реальных датасетах цепочки поставок оказался жёстким: в двух случаях из трёх ML уступил банальной сортировке. Разница — не в алгоритме, а в том, есть ли в данных обучаемый сигнал вообще.
Контекст
Задача на первый взгляд простая: у менеджера склада или отдела закупок сотни отгрузок в очереди, ресурс — проверить только 10%. Что смотреть первым — самое дорогое или то, что с наибольшей вероятностью задержится? Компромисс — взвешивать вероятность задержки на стоимость груза.
Автор тестировал три сценария на трёх датасетах: SCMS (данные закупок в здравоохранении), DataCo (корпоративная логистика) и Olist (e-commerce). Модель M1 = прогноз тяжести задержки × известная стоимость отгрузки. Конкуренты: VALUE_ONLY (сортировка только по стоимости) и severity-only (без весового коэффициента стоимости). Оценка честная — rolling-origin validation с жёстким контролем утечки данных и 1000 bootstrap-итераций для доверительных интервалов.
M1 обошёл severity-only во всех трёх датасетах — это ожидаемо. Но против VALUE_ONLY получилось иначе.
Аналитика
При бюджете проверки 10%: M1 против VALUE_ONLY — −5,5 pp для SCMS, +10,1 pp для DataCo, −4,9 pp для Olist. ML выиграл только у DataCo. Что его отличает? R² = 0,27 и калибровочное смещение +0,01 дня — модель реально умеет предсказывать тяжесть задержки. SCMS и Olist дали R² ≈ −0,02: модель хуже среднего, добавляет шум вместо сигнала.
Главный вывод не про алгоритм — про протокол. Прежде чем внедрять ML для приоритизации, нужно пройти «ворота обучаемости»: R² > 0 и положительная калибровка на rolling-origin eval. Не прошёл — остаёшься на сортировке по стоимости. VALUE_ONLY при этом не убирается никогда — это постоянный benchmark. Cost-sensitive retraining (обучение с учётом стоимости ошибки) эффекта не дал ни на одном датасете: нельзя «усилить» модель, у которой нет обучаемого сигнала.
Это важно шире логистики. Любая задача приоритизации — тикеты поддержки, лиды в CRM, кредитные заявки, медицинские случаи — подчиняется той же логике: сначала аудит обучаемости, потом ML. Иначе платишь за шум, который хуже простого правила.
Кейсы применения в бизнесе
B2B-SaaS стартап с логистическим или procurement-модулем. Перед тем как выкатить «AI-приоритизацию» как фичу, прогони rolling-origin eval на данных каждого клиента отдельно. Если R² < 0 — не продавай ML как решение: предложи VALUE_ONLY как базовый режим и ML как опцию с явным аудитом. Это честнее и безопаснее для репутации, чем продавать алгоритм, который проигрывает правилу.
Корпорация с legacy-процессами. Если в отделе уже стоит ML-решение для приоритизации заказов или заявок — выясни, сравнивали ли его с сортировкой по стоимости на реальных данных с rolling-origin. Скорее всего нет. Один такой аудит может заменить дорогой пайплайн бесплатным правилом — и это не поражение, а нормальная инженерия.
SMB и локальный бизнес в КР/СНГ. Для небольшого торгового или логистического бизнеса вывод прямой: сортируй по стоимости. Это рабочий baseline без затрат на разработку. Когда бизнес дорастёт до объёма, где можно измерить R², — тогда смотри на ML. До этого момента простое правило, вероятно, не хуже.
Кейсы в личной жизни
Data scientist или ML-инженер. Прежде чем предлагать заказчику модель ранжирования — прогони тест на обучаемость целевой переменной. Покажи R² и калибровочное смещение. Если оба плохие, честно скажи: «Данных для обучения нет, используй правило». Это не провал проекта — это профессионализм.
Аналитик / BI-специалист. Rolling-origin evaluation — стандарт для временных рядов. Если коллеги оценивают точность модели на случайном train/test split с данными о поставках — это утечка будущего в прошлое. Одна и та же модель выглядит хорошо на обычном split и плохо на rolling-origin. Разница может быть принципиальной.
Операционный менеджер без технического бэкграунда. Если вам продают AI-решение для приоритизации заявок или отгрузок, спроси три вещи: какой baseline использовался при сравнении, как именно оценивалась модель (rolling-origin или нет), какой R² получился на ваших данных. Нет чёткого ответа — перед вами маркетинг, а не продукт.
Как применить сегодня
- Добавь VALUE_ONLY (сортировка по стоимости/приоритетности) как постоянный baseline — он должен стоять рядом с любым ML в каждом отчёте и дашборде.
- Для любых временных или событийных данных используй rolling-origin split вместо случайного — иначе результаты метрик вводят в заблуждение.
- Посчитай R² для целевой переменной «тяжесть задержки/риска» перед обучением модели — отрицательный R² означает: ML здесь не поможет.
- Проверяй калибровку: модель с приемлемым R², но систематическим смещением на несколько дней даст неправильный приоритет даже при высокой точности.
- Перед питчем AI-вендору или внутренней команде — требуй сравнение с простым rule-based baseline на ваших данных, не на демо-датасете.