ColumnTransformer и remainder: куда исчезли новые столбцы таблицы

В API добавили поле loyalty. Сервис его принимает, ошибок нет, а прогноз не меняется. При разборе выясняется, что предобработка была обучена до появления поля. Разработчик ожидал, что remainder="passthrough" автоматически пропустит все новые столбцы, но эта настройка касается лишь полей, которые уже существовали во время fit и не были явно перечислены среди преобразователей.

Что сохраняет ColumnTransformer

ColumnTransformer определяет выходную схему при обучении. В примере возраст масштабируется, сумма покупок проходит без изменения. Позже приходит третье поле: кодировщик не добавляет его к матрице. Это правильное поведение для сохранения размерности, которую ожидает уже обученная модель, но молчаливое игнорирование может скрыть неудачный релиз API.

import pandas as pd
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import StandardScaler

train = pd.DataFrame({"age": [20, 30, 40], "spent": [100, 200, 300]})
new = pd.DataFrame({"age": [35], "spent": [250], "loyalty": [1]})
prep = ColumnTransformer([("age_scale", StandardScaler(), ["age"])],
                         remainder="passthrough").fit(train)
result = prep.transform(new)
print("выходные поля:", prep.get_feature_names_out().tolist())
print("форма:", result.shape)
print("значения:", result.round(3).tolist())
assert result.shape == (1, 2)
assert "loyalty" not in " ".join(prep.get_feature_names_out())

Выход содержит два поля — масштабированный возраст и сумму покупок. Форма (1, 2) сохраняется, loyalty отсутствует в get_feature_names_out(). Именно этот список стоит смотреть при разборе, а не только JSON запроса. Новый признак начнёт влиять на модель только после обновления preprocessing и переобучения самой модели на данных, где признак доступен.

Отличите игнорирование от перепутанного порядка

Здесь входное поле новое и отбрасывается. В другой распространённой ошибке те же старые поля передаются в ином порядке или под другими именами, и модель получает чужие значения; это разобрано в статье про схему признаков при predict. Для remainder с собственным преобразователем документация отдельно требует одинакового порядка столбцов DataFrame при fit и transform. Не считайте, что именованные колонки автоматически устраняют все риски порядка.

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

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

Контракт полезно проверять двумя независимыми условиями: вход не содержит неожиданных полей, а get_feature_names_out() совпадает с ожидаемой схемой обученной модели. Если дополнительные поля допустимы для других частей API, перечислите их отдельно и убедитесь, что команда продукта не считает их включёнными в прогноз. Такое явное правило лучше молчаливого игнорирования: оно делает изменение модели предметом отдельного релиза.

Курс «ML Engineer / Data Scientist: табличные модели в продакшн» соединяет подготовку признаков с валидацией, сохранением модели и REST-инференсом. На таком маршруте новая колонка становится проверяемым изменением пайплайна, а не случайным полем в запросе. Откройте программу курса.