Habr AI and Spar: how to test ML systems when data drifts and breaks predictions

На Habr AI вышел практический разбор тестирования ML-систем — не в теории, а на живом проекте автозаказа для сети Spar. Автор показывает, что у таких продуктов ломаются не только модели: ошибки прячутся в данных, сезонности, интеграциях и даже в выборе метрик.

Почему это сложно В классическом QA можно взять требования,

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

Как строят контроль В кейсе со

Spar команда ушла от идеи «найти один верный ответ» и опирается на технические и бизнес-метрики. На этапе требований сначала договариваются, что считать приемлемым качеством: например, насколько прогноз по категории может отклоняться от факта без реального ущерба для продаж и списаний. Дальше тесты строятся вокруг диапазонов, а не бинарного pass/fail.

Параллельно проверяют не только нормальные сценарии, но и аномальные данные, которые не должны ломать прогноз. На практике контроль собирается из нескольких слоёв: фиксированные версии библиотек и контейнеризация через Docker; обезличивание данных, чтобы использовать реалистичные продажи без утечки персональной информации; выборочное тестирование по разным магазинам, форматам и товарным категориям, а не только по средним метрикам; регрессия новой модели против старой, чтобы улучшение одной метрики не сломало другие; * мониторинг инфраструктуры и ночных обменов данными, потому что бизнесу важен не только точный, но и своевременный прогноз. Отдельный вывод статьи — тестировать ML «в среднем по больнице» бесполезно.

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

Факапы из продакшена Самая показательная часть материала — реальные сбои.

В одном случае команда перепутала два почти одинаковых параметра сезонного алгоритма: prediction_share и predict_share. Этого оказалось достаточно, чтобы система резко завысила прогноз по маслу, сметане и творогу. В магазины приехал лишний объём молочной продукции, а часть товара пришлось быстро распродавать с дисконтом из-за короткого срока годности.

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

Из-за низких объёмов продаж проблему заметили не сразу, но для покупателей эффект был простым: товар исчезал с полок именно тогда, когда был нужен. Ещё один сбой случился в начале 2025 года: модель некорректно интерпретировала поле year и фактически «не поняла», что наступил новый год, а система поиска аномалий это не отловила. Вывод жёсткий: ML нужно проверять не только на известных данных, но и на будущих периодах, новых диапазонах значений и отказах защитных механизмов.

Что это значит Статья Habr AI хорошо показывает сдвиг в самом понимании QA для ML.

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