Откат модели не помог: старый артефакт получил новые признаки

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

Версией релиза должна быть совместимая пара

Зафиксируйте рядом с моделью версию feature pipeline, схему полей, единицы измерения, допустимые значения и контрольные сырые события с ожидаемыми преобразованными признаками. При откате включайте совместимую версию подготовки данных либо явно подтверждённый адаптер. Сравнение только имён столбцов недостаточно: amount в рублях и копейках имеет одинаковый тип и положение.

Код показывает маленький контракт на уровне семантики. Две версии преобразования дают одинаковое имя выходного признака, но для одной и той же заявки различаются в сто раз. Проверка эталонного события обнаруживает это до вызова модели.

from dataclasses import dataclass

@dataclass(frozen=True)
class Release:
    model: str
    feature_version: str
    amount_unit: str

old_release = Release("model-v4", "features-v2", "rub")
event = {"amount_kopeks": 125000}

def prepare(raw, feature_version):
    if feature_version == "features-v2":
        return {"amount": raw["amount_kopeks"] / 100}
    if feature_version == "features-v3":
        return {"amount": raw["amount_kopeks"]}
    raise ValueError("unknown feature version")

expected = {"amount": 1250.0}
good = prepare(event, old_release.feature_version)
bad = prepare(event, "features-v3")
print("совместимо:", good, "несовместимо:", bad)
assert good == expected
assert bad != expected

Контрольная заявка даёт 1250 рублей для старого релиза и 125000 при новой обработке. В рабочей системе набор эталонов должен покрывать граничные случаи: нулевую сумму, валюту, пропуск, категорию из справочника и временную зону. Проверяйте результат подготовки до запуска прогноза; сама модель может принять неверную шкалу без ошибки.

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

Проверьте путь восстановления заранее

Храните манифест релиза как пару версий и тестируйте развёртывание старой пары в изолированной среде. Если признаки предоставляет отдельный онлайн-сервис, убедитесь, что он умеет отдавать прежнюю семантику или что входные сырые события доступны для повторной подготовки. Иначе «откатить модель» технически возможно, а восстановить прежнее поведение — нет.

Отдельная проблема с порядком столбцов на predict решается проверкой схемы. Здесь схема может совпадать, поэтому нужен эталон значения и версии преобразования.

Полезный smoke test запускается на входе, который проходит весь путь от сырого события до ответа API. Только проверка feature_names_in_ увидит пропавшее поле, но пропустит копейки вместо рублей и смену справочника категорий. Храните ожидаемые промежуточные признаки и итоговый ответ для нескольких таких запросов. При переключении релиза прогоняйте тест на той версии feature-сервиса, которая реально будет обслуживать трафик, а не на копии в ноутбуке.

В курсе «Data Scientist: от данных до деплоя моделей» feature engineering связан с воспроизводимостью, CI/CD и проверками перед релизом. Посмотрите программу курса, если хотите подготовить релиз, который можно действительно восстановить.