Какие ошибки делают команды, когда переносят notebook/prototype-подход на production data/AI pipeline?

2. Preprocessing и pipeline

# Типичная ошибка из notebook:
import pandas as pd
from sklearn.preprocessing import LabelEncoder

df = pd.read_csv('data.csv')
le = LabelEncoder()
df['category_encoded'] = le.fit_transform(df['category'])  # fit на всём датасете

# В production появляется новая категория — KeyError или silent garbage output

# Правильно для production:
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import OrdinalEncoder
import numpy as np

pipeline = Pipeline([
    ('encoder', OrdinalEncoder(
        handle_unknown='use_encoded_value',
        unknown_value=-1  # явная обработка новых категорий
    )),
])

Ошибки при переносе notebook/prototype в production pipeline

1. Данные и reproducibility

• Нет версионирования данных: notebook работает с CSV из локальной папки. В production непонятно, на каких данных обучена модель. Решение: DVC или MLflow Datasets для трекинга входных данных.
• Hardcoded paths: /Users/analyst/data/train.csv в коде. Решение: параметризация через конфигурационные файлы (Hydra, dynaconf) или переменные окружения.
• Отсутствие data validation: notebook предполагает определённую схему данных. В production схема меняется — нужен Great Expectations или pandera для валидации входных данных.

3. Leakage, которого не видно в notebook

• Feature engineering использует агрегаты по всему датасету (mean, std target encoding) — в production это будущие данные.
• Удаление выбросов по статистике всего датасета до split.
• Imputation missing values на полном датасете.

4. Модель как скрипт вместо сервиса

# Notebook-подход: скрипт, запускаемый вручную
model = pickle.load(open('model.pkl', 'rb'))
prediction = model.predict(X_test)
print(prediction)

# Production-подход: REST API через FastAPI
from fastapi import FastAPI
import joblib
import pandas as pd

app = FastAPI()
model = joblib.load('model.joblib')  # joblib лучше pickle для numpy arrays

@app.post('/predict')
def predict(features: dict):
    df = pd.DataFrame([features])
    prediction = model.predict(df)
    return {'prediction': int(prediction[0])}

5. Нет мониторинга и observability

• В notebook смотрим на accuracy на test set — в production модель деградирует незаметно.
• Нужны: логирование входных данных и предсказаний, PSI (Population Stability Index) для feature drift, мониторинг prediction distribution.

6. Зависимости и окружение

• Notebook работает в Jupyter с conda install без фиксации версий. В production нужен requirements.txt с точными версиями или Poetry/pip-tools.
• Разные версии scikit-learn в notebook и production — другие результаты predict.

Подводные камни

• Переносить notebook cell-by-cell в Python скрипт без рефакторинга — глобальные переменные, отсутствие функций, no error handling.
• Не тестировать pipeline на новых категориях / NaN / out-of-range значениях — notebook обычно работал с «чистыми» данными.
• Использовать LabelEncoder для категориальных признаков в production — не обрабатывает unseen categories.
• Не логировать версию модели вместе с предсказаниями — при инциденте невозможно понять, какая модель дала плохой результат.
• Деплоить модель без A/B теста — резкий переход на новую модель без сравнения с production baseline.
• Не настроить retraining pipeline — через 3 месяца данные дрейфуют, модель деградирует без обновления.
• Хранить модель в git как бинарный файл — репозиторий раздувается, используйте MLflow Model Registry или S3.
• Игнорировать inference time на production объёмах — то, что работало за 1 секунду в notebook на 1000 строк, занимает 5 минут на 1M строк.

• Говорить только о запуске scikit-learn, но не об эксплуатации
• Не упоминать observability, обновления, безопасность и rollback
• Описывать риски абстрактно, без способов их снижать

• Видит production-риски scikit-learn
• Говорит про monitoring, rollout, rollback и безопасность
• Умеет ранжировать риски по вероятности и влиянию