Настройка Feature Store (Feast, Tecton) для управления признаками

Feature Store: почему признаки расходятся между обучением и продом

Признаки для модели считаются в двух разных местах. При обучении их собирают запросом к историческим данным — пакетно, по всей доступной глубине. В работе модели те же признаки приходят из онлайн-хранилища, по одному объекту, с минимальной задержкой. Пока обе реализации совпадают, метрики на отложенной выборке и в эксплуатации сходятся.

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

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

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

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

Что даёт единый слой признаков при разработке моделей

Признак почти всегда живёт в нескольких местах: расчёт в скрипте аналитика, копия в тетради моделиста, третья версия — в сервисном коде. Расхождение не видно, пока модель обучается на одной выборке, а на входе получает другую, — и всплывает в проде, когда качество падает без изменений в самой модели. Единый слой признаков (Feature Store) убирает эту развилку: определение описывается один раз и материализуется в офлайн- и онлайн-хранилище — открытые каталоги вроде Feast строятся вокруг такого реестра.

• Время подготовки данных. Новый признак описывается один раз: цикл от идеи до значения в модели сокращается с недель до дней — не нужно заново собирать и сверять расчёты.
• Повторное использование признаков. Каталог показывает, что уже посчитано, кто владелец и насколько свежи значения, — дубли не появляются, а новый расчёт надстраивается над готовым.
• Один источник значений для обучения и работы модели. Обучение и онлайн-выдача читают согласованные определения, поэтому распределение признаков в проде совпадает с проверочным.
• Устранённый класс отказов из-за рассинхронизации. Разные версии логики расчёта и ручные копии перестают ломать качество: сценарий закрыт на уровне платформы, а не регламентом.
• Воспроизводимость. У каждой обучающей выборки фиксируется срез признаков на момент времени — прежний результат можно повторить и объяснить.
• Контроль доступа. Один каталог с ролями, владельцами и историей изменений вместо согласований в переписке.

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

Feature Store: сравнение вариантов реализации

Варианты реализации Feature Store различаются по двум осям: нужны ли признаки в момент запроса и как часто меняется их состав. Если модель пересчитывается по расписанию и задержка в часы допустима, сложный контур не нужен.

Если признаки уходят в онлайн-сервис и одна логика расчёта обслуживает и обучение, и выдачу, без реестра и синхронизации слоёв не обойтись — расхождение между ними видно уже на проде. Разница между вариантами не в объёме работ, а в том, что остаётся на вашей команде.

Варианты и их ограничения

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

Как мы внедряем слой признаков: этапы работ

Внедрение слоя признаков — это не установка библиотеки, а наведение порядка в том, откуда модели берут входные данные. Сначала разбираем источники: какие таблицы, события и выгрузки реально питают обучение и инференс, кто владелец, с какой частотой они обновляются и где значения расходятся. От этого зависит схема потоков и то, какие признаки вообще имеет смысл считать переиспользуемыми.

1. Аудит источников данных. Инвентаризация таблиц и событий: владелец, частота обновления, задержка появления, история изменений. Результат — карта источников с пометкой, какие годны для обучения, а какие только для аналитики.
2. Проектирование схемы потоков. Фиксируем ключи, гранулярность, окна и версии: одна и та же логика должна считаться одинаково для исторических данных и для онлайн-запроса.
3. Настройка расчёта и хранения. Поднимаем хранилище признаков (Feature Store): офлайн-слой для обучения, онлайн-слой для отдачи в момент запроса, реестр определений. Признаки описываем декларативно, чтобы формулу не переписывали заново в каждой команде.
4. Проверка качества признаков. Сверяем офлайн и онлайн: одно событие должно давать одинаковый вектор в обоих слоях. Ловим пропуски, дрейф распределений и устаревшие значения на тестовом контуре, а не в бою.
5. Вывод в эксплуатацию. Настраиваем расписание обновлений, контроль задержек и оповещения о расхождениях, чтобы деградация данных была видна до того, как её заметит модель.
6. Передача документации и обучение. Реестр признаков, схемы потоков, регламент добавления новых признаков и разбора инцидентов. Проводим разбор с инженерами и аналитиками, чтобы слой расширялся внутри команды.

Что передаём на руки: конфигурации, схемы, регламенты

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

• Конфигурации окружений — тестовый, предпродуктивный и продуктивный контуры с раздельными источниками и расписаниями; развёртывание воспроизводится из репозитория, а не «по памяти».
• Карта признаков — реестр с владельцем, источником, типом, частотой обновления и списком потребителей; заранее видно, какие модели затронет правка или удаление.
• Схемы потоков данных — путь от источника до обучающей выборки и онлайн-выдачи: где происходит трансформация, где хранится срез, где точка отказа.
• Политики доступа команд — роли на чтение, запись и изменение определения признака; права выдаются по ролям, а не раздачей общих ключей.
• Регламенты обновления — порядок добавления признака, вывода из эксплуатации и проверки совместимости с уже обученными моделями, с указанием согласующих.
• Контроль качества данных — проверки свежести, доли пропусков и расхождения между срезом для обучения и онлайн-значением; деградация видна до падения качества предсказаний, а не после.
• Документация для поддержки — точки восстановления, порядок отката версии признака, ответственные за источники и типовые сбои с готовыми действиями.

Кейс: как убрали расхождение признаков между средами

Как было

Данные для обучения и для онлайн-расчёта собирали двумя независимыми ветками: аналитики — запросами к хранилищу, сервис модели — своими скриптами предобработки. Витрину с десятками признаков пересобирали под каждую новую модель, а обработка пропусков и категориальных полей в этих ветках расходилась. Подготовка занимала 4–5 дней, и примерно треть моделей после выкладки приходилось откатывать — значения признаков в обучении и в рабочем контуре не совпадали.

Что изменили

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

Подготовка витрины сократилась с 4–5 дней до нескольких часов, доля инцидентов из-за расхождения значений упала с трети до единичных случаев за квартал. Время отклика онлайн-расчёта уменьшилось втрое и перестало зависеть от размера исторического окна. Откат модели стал штатной операцией: признаки версионируются вместе с моделью, и результат воспроизводится на любой предыдущей версии.

Чем витрина признаков отличается от хранилища данных?

Хранилище данных решает задачу сохранности и доступа: как записать события без потерь при сбое и как выдать аналитику согласованный срез. Витрина признаков решает другую задачу — воспроизводимость значений: какое число получала модель на входе в момент конкретного события и откуда оно взялось.

Отсюда первая разница — расчёт привязан ко времени. Хранилище отдаёт текущее состояние записи, слой признаков отдаёт её состояние на момент события, без данных из будущего. Если этой границы нет, в обучающую выборку просачиваются значения, которых тогда не существовало, и качество модели на проверке оказывается выше, чем в эксплуатации.

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

Третья — контракт вместо запроса. Признак описывается именем, типом, источником, окном агрегации, расписанием пересчёта и ответственным. Пока этого нет, каждая команда считает метрику по-своему, и на разборе качества модели выясняется, что сравнивать нечего.

Практический критерий простой: если одна и та же логика расчёта повторяется в запросах третий раз, её место в витрине признаков. Каталог определений уровня Feast или Tecton хранит их как код, синхронизирует оба контура и оставляет историю изменений — хранилище данных такую задачу не решает.

Частые технические вопросы по слою признаков

Перед стартом инженеры задают одни и те же вопросы: как слой признаков (Feature Store) встанет на текущее озеро данных, что делать с уже накопленной историей и как развести команды по правам. Ниже — короткие ответы по каждому пункту.

Что делать с историческими данными за прошлые периоды?

Историю подтягиваем пакетно из накопленных срезов и строим точечные значения на нужные даты, поэтому признаки для обучения собираются задним числом. Расхождение между обучающей выборкой и выдачей в проде убирается: обе стороны читают один расчёт.

Как версионируются определения признаков?

Каждое изменение — новая версия определения, прежняя остаётся доступной. Модель закрепляется за конкретной версией, поэтому пересчёт признаков не ломает работающие модели, а откат — это переключение ссылки на предыдущую версию.

Как разграничить доступ между командами?

У каждой команды своё пространство имён и права на чтение и запись; чужие признаки доступны только через опубликованные наборы. Владелец признака указан в описании — видно, с кем согласовывать изменение.

Обсудим задачу: что нужно для старта работ

Чтобы вернуться с оценкой и планом внедрения, а не с общими словами, нам нужно увидеть ваш контур работы с признаками. Для старта работ достаточно показать то, что перечислено ниже, — остальное уточним вопросами на разборе задачи.

• Источники данных: какие системы порождают события, с какой частотой и в каком виде они попадают в аналитику.
• Текущий расчёт признаков: скрипты, ноутбуки или периодические выгрузки, из которых собираются обучающие выборки, и кто их поддерживает.
• Требования к свежести: какие признаки нужны онлайн в момент запроса, а какие допустимо считать пакетно раз в сутки.
• Инфраструктура: где запускается обучение и вывод модели в прод, какие хранилища уже используются и что нельзя менять.
• Объёмы и рост: число сущностей, количество признаков, требуемая глубина истории за прошлые периоды.
• Разграничение доступа: требования к изоляции данных и к тому, кто получает доступ к признакам.
• Расхождения, которые уже ловили: чем отличались значения признаков при обучении и в онлайн-выдаче и к чему это привело.
• Ответственные: кто подтверждает состав работ и принимает результат по этапам.

Этого достаточно, чтобы оценить трудоёмкость и риски. После разбора вернёмся с составом работ, схемой хранилища признаков (Feature Store) и планом внедрения по этапам — с точками контроля результата и порядком отката, если на каком-то шаге что-то пойдёт не так.