Команда обучила модель, метрики на тесте отличные, заказчик доволен. Через три месяца в проде модель выдаёт мусор, и никто не может объяснить почему. Знакомая история. Чаще всего корень один – данные, на которых учили модель, и данные, которые приходят в продакшен, расходятся, а воспроизвести исходный обучающий набор уже нельзя. Зрелый MLOps начинается не с оркестрации обучения, а с дисциплины работы с данными и признаками.

Feature store: единый источник признаков

Признак (feature) – это не сырое поле из базы, а результат расчёта: средний чек клиента за 30 дней, доля просроченных платежей, эмбеддинг изображения. Проблема в том, что эту логику обычно пишут дважды: один раз на Python в Jupyter при обучении, второй раз на SQL или Java в боевом сервисе. Две реализации неизбежно расходятся и модель в проде получает не те входы, на которых училась. Это train/serving skew, тихий убийца качества.

Feature store снимает проблему. Это слой между хранилищем данных и моделями, который рассчитывает признаки один раз и отдаёт их в двух режимах: офлайн (исторические значения для обучения, большими батчами) и онлайн (актуальное значение по ключу за миллисекунды для инференса). Одна и та же логика, один контракт. В 2020 году Feast стал заметным open-source решением в этой нише, а крупные команды описали внутренние платформы – от Uber Michelangelo до подходов в банках и телекоме.

Для госсектора и регулируемых отраслей есть отдельный бонус – прозрачность. Когда регулятор или внутренний аудит спрашивает, на основании каких данных модель приняла решение по заявке гражданина или клиента, feature store даёт точный ответ с привязкой ко времени. Это особенно важно там, где ИИ работает с физическими процессами и изображениями – см. наш разбор компьютерного зрения в промышленности.

Версионирование данных: воспроизводимость как требование

Код вы версионируете в Git. Данные – нет, а зря. Без снапшота обучающего набора эксперимент невоспроизводим: вы не докажете, что новая версия модели лучше старой, потому что не знаете, на одних ли данных их сравнивали.

Практический минимум выглядит так:

  • Версия датасета – фиксируем точный срез данных, использованный для обучения. Инструменты вроде DVC связывают версию данных с коммитом кода.
  • Версия признаков – feature store хранит определения признаков и их историю изменений, чтобы перерасчёт через год дал тот же результат.
  • Версия модели – артефакт модели плюс ссылки на версии данных и признаков, на которых она получена.

Связка этих трёх версий и есть воспроизводимость. Без неё MLOps превращается в набор ручных героических усилий, которые рушатся при уходе ключевого инженера.

С чего начать на практике

Не стройте платформу мечты сразу. Начните с одной модели в проде, у которой уже болит train/serving skew. Вынесите расчёт её признаков в общий слой, заведите версионирование датасета, замерьте, насколько разъезжаются офлайн- и онлайн-значения. Этот пилот окупит себя быстрее, чем большая стройка.

Подход хорошо ложится на low-code-инструменты для сборки пайплайнов – об этом мы писали в материале про год low-code. А вопросы налогового оформления самой разработки разбирали в заметке про льготу по НДС на ПО.

Вывод

Feature store и версионирование данных – это не модный слой поверх ML, а фундамент, без которого модели в проде деградируют незаметно и неуправляемо. Сначала дисциплина данных, потом автоматизация обучения. Если вы выстраиваете промышленный ИИ для бизнеса или госсектора, начните с этого фундамента – он закладывается ещё на этапе проектирования интеллектуальных систем для прода.