7 промптов для прогнозирования и ML-моделирования

Помоги построить прогноз временного ряда.

Контекст:
Что прогнозируем: [продажи / трафик / загрузка серверов / спрос].
Гранулярность: [час / день / неделя / месяц].
Глубина истории: [сколько периодов есть данных].
Горизонт прогноза: [на сколько вперёд].
Сезонность (известная): [недельная / месячная / годовая / нет].
Внешние факторы (если есть): [промо-акции / праздники / погода / макроэкономика].

План работы:

1) EDA временного ряда:
Тренд (есть ли направленное движение).
Сезонность (декомпозиция STL).
Стационарность (ADF тест).
Аномалии и выбросы.

2) Выбор модели:
**Простые baseline:**
Naive (последнее значение / среднее).
Seasonal naive (значение год назад).
Moving average / Exponential smoothing.
**Классические:**
ARIMA / SARIMA — для стационарных рядов с сезонностью.
Prophet (Facebook) — robust, легко интерпретируется, держит holidays.
**ML:**
XGBoost / LightGBM на feature-engineered признаках (lags, rolling, calendar features).
**Deep Learning:**
LSTM / Transformer — для очень длинных рядов с нелинейностями. Для коротких рядов overkill.

3) Метрики качества:
MAE — средняя абсолютная ошибка (в единицах).
MAPE — средняя процентная ошибка (не работает на нулях).
RMSE — штрафует крупные ошибки.
Какую выбрать — зависит от бизнес-смысла.

4) Кросс-валидация для time series:
TimeSeriesSplit (НЕ random!).
Walk-forward validation.
Никогда не использовать будущие данные для тренировки прошлых (data leakage).

5) Доверительные интервалы — обязательно. Прогноз без них вводит в заблуждение.

6) Готовый код на Python (Prophet — самый простой старт):
```python
from prophet import Prophet
import pandas as pd

df = pd.read_csv('data.csv')
df.columns = ['ds', 'y']

model = Prophet(
    yearly_seasonality=True,
    weekly_seasonality=True,
    interval_width=0.95
)
model.fit(df)

future = model.make_future_dataframe(periods=30)
forecast = model.predict(future)
```

Запрет: прогноз без доверительных интервалов, экстраполяция на горизонт длиннее 30% от истории данных, использование random train/test split на time series.

Помоги построить регрессионную модель.

Контекст:
Что прогнозируем (numeric target): [цена квартиры / время выполнения / сумма следующего заказа / etc].
Признаки (features): [список или описание dataset'а].
Размер выборки: [N строк × M колонок].
Бизнес-цель прогноза: [что будем делать с предсказаниями].

План:

1) EDA + feature engineering:
Распределения признаков, корреляции, выбросы.
Категориальные → one-hot / target encoding.
Числовые → нормализация (если модель чувствительна).
Новые признаки (взаимодействия, log-преобразования, polynomial).
Обработка пропусков (mean / median / model-based imputation).

2) Выбор модели по сложности данных:
**Линейная регрессия** — baseline, интерпретируемая. Если зависимость линейная и признаков мало — лучший выбор.
**Ridge / Lasso / ElasticNet** — регуляризация для много признаков и мультиколлинеарности.
**Random Forest / Gradient Boosting (XGBoost, LightGBM, CatBoost)** — нелинейные зависимости, обработка категориальных. Default выбор для табличных данных в 2026.
**Нейросети** — для очень больших выборок (1M+) и сложных нелинейностей. Чаще всего overkill.

3) Метрики:
MAE — интерпретируемая, устойчива к выбросам.
RMSE — штрафует большие ошибки.
R² — доля объяснённой дисперсии (0..1, чем выше тем лучше).
MAPE — для процентной интерпретации.
**Бизнес-метрика** — обязательно перевести точность модели в деньги / ресурсы.

4) Кросс-валидация:
K-Fold (k=5 стандарт).
Stratified — если есть субпопуляции в данных.
GroupKFold — если в данных есть зависимости (например, несколько строк от одного пользователя).

5) Интерпретация:
Важность признаков (feature importance / SHAP values).
Partial dependence plots.
Конкретные примеры предсказаний с объяснением (особенно если будете оправдываться перед бизнесом).

6) Готовый код (LightGBM):
```python
import lightgbm as lgb
from sklearn.model_selection import KFold
from sklearn.metrics import mean_absolute_error

model = lgb.LGBMRegressor(
    n_estimators=500,
    learning_rate=0.05,
    early_stopping_rounds=50
)
kf = KFold(n_splits=5, shuffle=True, random_state=42)
scores = []
for train_idx, val_idx in kf.split(X):
    model.fit(
        X.iloc[train_idx], y.iloc[train_idx],
        eval_set=[(X.iloc[val_idx], y.iloc[val_idx])]
    )
    pred = model.predict(X.iloc[val_idx])
    scores.append(mean_absolute_error(y.iloc[val_idx], pred))
```

Запрет: финальная модель без кросс-валидации (одной train/test split недостаточно), сложная модель без сравнения с простым baseline (часто Linear Regression не уступает XGBoost), отсутствие feature importance.

Помоги построить классификационную модель.

Контекст:
Что классифицируем: [уйдёт ли клиент / одобрить кредит / тип обращения / спам vs не-спам].
Тип задачи: [binary / multiclass / multilabel].
Распределение классов (балансировка): [сбалансированные / дисбаланс какой степени].
Цена ошибок:
False Positive (предсказали +, на самом деле −): [последствие].
False Negative (предсказали −, на самом деле +): [последствие].

План:

1) EDA + balancing:
Распределение классов.
Если дисбаланс >1:10 — обработать (SMOTE / undersampling / class weights).
Признаки vs target — корреляции.

2) Выбор модели:
Logistic Regression — baseline, интерпретируемая.
Random Forest / Gradient Boosting — нелинейные.
SVM — для маленьких выборок с чёткой границей.
Neural Networks — для очень больших / сложных задач (NLP, computer vision).

3) Метрики (для дисбаланса Accuracy НЕ подходит):
**Confusion matrix** — основа всего.
Precision = TP / (TP + FP) — какая доля предсказанных «+» реально «+».
Recall = TP / (TP + FN) — какую долю реальных «+» поймали.
F1 = 2 × P × R / (P + R) — балансир.
ROC-AUC — для ранжирования (порядок важнее порога).
PR-AUC — для дисбалансных задач.

**Какая метрика бизнес-критична?**
Спам-фильтр: важнее Precision (не блокировать настоящие письма).
Скрининг рака: важнее Recall (не пропустить больного).
Кредит: бизнес сам решает (баланс лимита риска).

4) Threshold tuning:
Default 0.5 — почти никогда не оптимален.
Найти threshold по PR-curve / F1-curve / бизнес-функции.

5) Probability calibration:
Если используете predict_proba — проверьте калибровку (Brier score, calibration plot).
Деревья и SVM часто плохо откалиброваны — нужен CalibratedClassifierCV.

6) Код (Logistic + class weights):
```python
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import classification_report, roc_auc_score

model = LogisticRegression(
    class_weight='balanced',
    max_iter=1000
)
model.fit(X_train, y_train)
y_pred = model.predict(X_test)
y_proba = model.predict_proba(X_test)[:, 1]
print(classification_report(y_test, y_pred))
print(f'ROC-AUC: {roc_auc_score(y_test, y_proba):.3f}')
```

Запрет: использование Accuracy на дисбалансных данных (даёт иллюзию качества), single threshold 0.5 без оптимизации, отсутствие анализа ошибок (какие именно примеры модель путает).

Помоги провести кластеризацию для сегментации (клиентов / товаров / транзакций).

Контекст:
Что кластеризуем: [конкретно].
Объекты: [N штук с M признаками].
Бизнес-цель: [таргетинг кампаний / персонализация / выявление аномальных групп].
Известные категории (если есть): [или unsupervised полностью].

План:

1) Feature engineering:
Все признаки — численные (категориальные → one-hot или embeddings).
Нормализация (StandardScaler / MinMaxScaler) — обязательно для distance-based методов.
PCA / UMAP для уменьшения размерности (если M > 20).

2) Выбор алгоритма:
**K-Means** — быстрый, простой, требует знания K. Хорош для сферических кластеров одинакового размера.
**Hierarchical (Ward)** — даёт дендрограмму, удобно интерпретировать.
**DBSCAN** — находит кластеры произвольной формы, выявляет outliers. Не требует K.
**Gaussian Mixture Models** — soft clustering (вероятности принадлежности).
**HDBSCAN** — улучшенный DBSCAN, часто лучший дефолт.

3) Определение оптимального K (для K-Means):
Elbow method — изгиб на графике WCSS.
Silhouette score — выше = лучше разделение.
Gap statistic.
**Бизнес-логика > математика** — если K=7 даёт лучший silhouette, но бизнес может работать с 4 сегментами — берите 4.

4) Профилирование кластеров — **самый важный шаг!**:
Средние значения каждого признака по кластеру.
Размеры кластеров.
Названия (по доминирующим характеристикам — например: «Премиум-молодые», «Бюджетные-лояльные»).
Если кластер не интерпретируется — он бесполезен для бизнеса.

5) Валидация:
A/B тест на разных сегментах (одинаково ли реагируют на стимулы).
Стабильность во времени (кластеризация на свежих данных даёт похожие сегменты?).

6) Код:
```python
from sklearn.cluster import KMeans
from sklearn.preprocessing import StandardScaler
from sklearn.metrics import silhouette_score

scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)

# Поиск оптимального K
for k in range(2, 11):
    model = KMeans(n_clusters=k, random_state=42, n_init=10)
    labels = model.fit_predict(X_scaled)
    score = silhouette_score(X_scaled, labels)
    print(f'K={k}: silhouette={score:.3f}')
```

Запрет: кластеры без интерпретации (если не можете назвать — бесполезно), K-Means без нормализации (доминируют признаки с большими значениями), использование на категориальных без преобразования.

Помоги системно сравнить несколько моделей для выбора лучшей.

Контекст:
Тип задачи: [регрессия / классификация].
Главная метрика: [конкретная].
Бизнес-ограничения: [скорость inference / интерпретируемость / размер модели].
Кандидаты на сравнение: [список — например: Linear, Random Forest, XGBoost, LightGBM, CatBoost, Neural Net].

Структура сравнения:

1) Унифицированный pipeline:
Одинаковая предобработка для всех моделей.
Одинаковое разбиение train/val/test.
Одинаковые метрики.
Random seed зафиксирован.

2) Hyperparameter tuning для каждой:
GridSearchCV / RandomizedSearch / Optuna.
**Одинаковый бюджет времени** — иначе нечестно (XGBoost будет выглядеть лучше Linear, потому что больше тюнили).
Стандартные сетки гиперпараметров из best practices, не ad-hoc.

3) Метрики для сравнения (минимум 4):
Главная бизнес-метрика (F1 / MAE / etc).
Скорость inference (мс на предсказание) — критично для real-time.
Скорость training (для переобучения).
Размер модели (МБ) — для edge deployment.
Интерпретируемость (subjective scoring 1-5).
Робастность (как падает качество на «слегка изменённых» данных).

4) Cross-validation на k=5 минимум:
Среднее ± стандартное отклонение по фолдам.
Если разница между моделями меньше std — статистически не значимая, простую модель брать.

5) Сводная таблица:
Модель | F1 | Inference (мс) | Train (мин) | Размер (МБ) | Interpretability | Recommendation

6) Финальное решение:
Бизнес-обоснование выбора, не только «у этой выше F1».
Если модель А лучше А-Б на 1%, но в 100 раз медленнее — берём Б.

Принципы:
Простая модель с meaningful результатом > сложная с marginal улучшением.
Время на feature engineering > время на выбор модели в 90% случаев.
Ensemble нескольких моделей часто > single best, но сложнее в продакшене.

Запрет: сравнение без одинакового tuning budget (нечестно), сравнение только по одной метрике (упрощение), выбор сложной модели без бизнес-оправдания (перфекционизм без ROI).

Помоги проверить модель на переобучение (overfitting) и корректность.

Контекст:
Модель: [какая].
Метрика на train: [значение].
Метрика на test: [значение].
Размер выборки: [N].

Чек-лист на overfitting:

1) **Train vs Test gap:**
Если train F1 = 0.95, test F1 = 0.65 — overfit очевиден.
Если разница <5% — обычно ок.
Если train F1 = test F1 = низкий — underfit (модель слишком слабая).

2) **Learning curves:**
Plot train/val метрики как функция размера выборки.
Если train flat высокий, val flat низкий — overfit.
Если оба растут — нужно больше данных.

3) **Validation curves:**
Plot train/val метрик как функция гиперпараметра (complexity).
Найти оптимум (где val максимум).

4) **Cross-validation consistency:**
Стандартное отклонение по фолдам.
Если std большая — модель нестабильна, чувствительна к выборке.

5) **Shuffle test:**
Перемешайте target случайно.
Заново обучите модель.
Метрика должна упасть до random baseline. Если нет — data leakage.

6) **Holdout test set:**
Должен быть **никогда не виданный** моделью set.
Не использовать для tuning.
Финальная оценка только на нём.

Стратегии борьбы с overfit:
**Больше данных** — лучшее лекарство.
**Регуляризация** (L1/L2/dropout/early stopping).
**Упрощение модели** (меньше deep, меньше features).
**Feature selection** (только важные признаки).
**Ensemble** (bagging/boosting).
**Data augmentation** (для изображений / NLP).

Стратегии борьбы с underfit:
Более сложная модель.
Больше features (feature engineering).
Снизить регуляризацию.
Дольше тренировать.

Запрет: использование test set для tuning (test уходит в train неявно), отсутствие holdout для финальной оценки, игнорирование стандартного отклонения по фолдам.

Помоги задеплоить ML-модель в продакшен.

Контекст:
Модель: [тип, размер, framework].
Сценарий использования: [batch / real-time / edge].
Ожидаемая нагрузка: [requests/sec].
SLA на latency: [мс].
Инфраструктура: [AWS / GCP / VPS / on-premise].

Чек-лист деплоя:

**1. Сериализация модели:**
pickle / joblib (Python native, простое).
ONNX (cross-platform, быстрее).
TorchScript / TensorFlow SavedModel.
Версионирование (MLflow / DVC / Weights & Biases).

**2. API endpoint:**
FastAPI / Flask — простой REST.
Triton / TorchServe — оптимизированы для ML.
gRPC — низкая latency.
Контракт: input schema, output schema, версионирование API.

**3. Препроцессинг consistency:**
Тот же scaler, encoders, imputers, что были в training.
Сериализуйте preprocessor вместе с моделью.
Тестируйте: production preprocessing должен дать те же признаки, что и в training (byte-identical).

**4. Performance:**
Latency p50, p95, p99 (не только среднее).
Throughput (RPS).
Memory usage.
Batching для эффективности.

**5. Monitoring:**
**Data drift** — статистика входных признаков в проде vs training.
**Model drift** — снижение метрик качества на production-данных.
**Prediction distribution** — распределение outputs.
**Latency tracking.**
**Error rate.**
Алерты на отклонения.

**6. Логирование:**
Каждое предсказание (privacy-aware).
Inputs (анонимизированные).
Outputs.
Confidence / probabilities.
Время.
Для аудита и переобучения.

**7. Retraining стратегия:**
Триггеры (drift detected / по расписанию / новые labeled данные).
A/B тест новой модели vs старой.
Shadow deployment (параллельный запуск без влияния на пользователей) — для сравнения.
Canary deployment (на 5% трафика → 100%).
Rollback план.

**8. Безопасность:**
Authentication / authorization.
Rate limiting.
Input validation (защита от adversarial examples и DoS).
PII handling.

Принципы:
**Модель в продакшене — это только 10% работы**. 90% — MLOps инфраструктура.
Никогда не деплойте без monitoring — модель будет деградировать, и вы узнаете слишком поздно.
A/B тест перед заменой production-модели — обязательно. «Лучше в offline» ≠ «лучше в production».

Запрет: деплой без monitoring (медленная деградация = катастрофа), обновление модели без A/B теста (не знаете, улучшение или регресс), preprocessing inline в коде вместо сериализованного артефакта (training/serving skew гарантирован).