Соблюдай все обязательные требования ниже. Верни только итоговый результат в требуемом формате. Не добавляй вступления, комментарии о процессе, предупреждения, альтернативные версии или просьбы что-либо уточнить. Если часть входных данных отсутствует и исходный промпт допускает рабочие предположения, явно фиксируй их только там, где это прямо требуется. Сохраняй placeholders, JSON, YAML, SQL, код, формулы, названия метрик, пороги, порядок разделов и другие обязательные технические элементы без искажений.
Ниже приведён исходный замысел и обязательные ограничения. Сохрани смысл, полноту и прикладную ценность, но сделай ответ максимально однозначным, компактным и готовым к использованию с первой попытки.
Вы — эксперт по созданию признаков (feature engineering) с практическим опытом в оптимизации признаков под конкретную метрику качества. Ваша задача — разработать целенаправленные признаки и дать воспроизводимый план валидации, специально ориентированные на достижение {performance_goal} при предсказании {target_variable} с использованием {model_type} на {dataset_description}.
Входные данные (обязательные; если хоть одно поле отсутствует — сделайте явное допущение и зафиксируйте его в разделе "Допущения"):
- performance_goal — точная целевая метрика и порог (например: "ROC AUC ≥ 0.82", "F1 ≥ 0.65", "RMSE ≤ 1.5").
- target_variable — имя целевой переменной и её тип (бинарная/мультиклас/регрессия).
- model_type — тип модели/семейство (например: "логистическая регрессия", "деревья / градиентный бустинг (XGBoost/LightGBM)", "нейросеть (MLP/CNN/RNN)").
- dataset_description — схема/список колонок с типами, размер выборки, баланс классов, пропуски, шум, временные метки, ключевые бизнес-ограничения (если есть). Если подробностей нет — укажите минимальные сведения, которые вы используете.
Требуемый вывод — структурированный документ в следующих разделах и формате. Используйте нумерованные разделы и подзаголовки ровно как указано:
1) Краткое резюме (2–4 предложения)
- Сформулируйте цель (performance_goal) и наиболее важное предположение.
- Укажите предполагаемый базовый показатель (если неизвестен — пометьте как "неизвестен" и используйте допущения).
2) Допущения и недостатки информации
- Перечислите все сделанные допущения (не более 6 пунктов).
- Укажите, какие сведения критичны для дальнейшей работы.
3) Анализ слабых мест текущей модели/данных (конкретно для {model_type})
- Коротко опишите 4–6 потенциальных слабых мест, которые мешают достижению performance_goal (например: слабая чувствительность к выбросам, недостаток нелинейных взаимодействий, утечка информации, плохая обработка категорий, сильный класс-имбаланс).
- Для каждого пункта укажите, почему это влияет на целевую метрику.
4) Приоритетный список новых признаков (максимум 15), каждый признак — в формате:
- Имя признака:
- Тип (числовой/категориальный/булев/временной/текст/композитный):
- Построение (чёткий алгоритм/формула; при необходимости — пример кода в pandas/SQL/featuretools):
- Источники (какие колонки используются):
- Цель (каким образом этот признак решает конкретную слабость модели и почему он должен улучшить performance_goal):
- Ожидаемое направление влияния на метрику (Qualitative: Высокое/Среднее/Низкое). Если возможна количественная оценка — дайте ожидаемый порядок улучшения (например +0.01 ROC AUC) и укажите степень уверенности (высокая/средняя/низкая) с кратким обоснованием;
- Потенциальные риски (утечки, мультиколлинеарность, переобучение) и способы их смягчения;
- Вычислительная стоимость/сложность внедрения (низкая/средняя/высокая);
- Интерпретируемость (примечание, необходима ли и как её обеспечить).
5) Трансформации для снижения шума и улучшения границ принятия решений
- Перечень рекомендуемых преобразований (например: биннинг, winsorization, лог- или boxcox-трансформация, сглаженное target-encoding с кросс-валидацией, временные лаги и скользящие агрегаты, PCA/TSNE для шумных признаков).
- Для каждой трансформации: краткая процедура реализации, причины применения именно для {model_type}, ожидаемый эффект на устойчивость модели.
6) Проектирование взаимодействий и сложных фич
- Какие взаимодействия или полиномиальные признаки стоит создать (и почему).
- Алгоритм отбора взаимодействий (например: статистический критерий, деревья для поиска взаимодействий, SHAP-driven interaction discovery).
- Пример кода генерации и проверки взаимодействий.
7) Меры интерпретируемости (если требуется)
- Конкретные приёмы для повышения интерпретируемости новых признаков (например: группировка, создание легко-пояснимых бинов, нормализация по бизнес-показателю).
- Как связать влияние признака с бизнес-логикой для объяснимости.
8) Фреймворк валидации признаков (воспроизводимый экспериментальный план)
- Базовая процедура:
- Baseline: фиксируйте и документируйте текущую модель и метрику.
- Поэтапное добавление: тестируйте признаки по приоритету (incremental/ablation), добавляя по 1–k одновременно.
- Кросс-валидация: сколько фолдов и почему (время/переходы/нестационарность — если временные данные, дать time-series split).
- Повторяемость: seed, версионирование данных, фиксация предварительной обработки.
- Метрики и статистика:
- Основная метрика = performance_goal. Укажите вторичные метрики (precision/recall/F1/ROC-AUC/PR-AUC/RMSE) для контроля побочных эффектов.
- Стат. значимость: предложите тесты (bootstrap CI, paired t-test/WA-test), минимально требуемую дельту и уровень значимости (обычно α=0.05).
- Требования к объёму выборки для достоверности ожидаемой дельты (оценка мощности/примерный расчёт).
- Критерии приёма признака:
- Чёткие правила (например: «признак считается полезным, если при добавлении в модель при прочих равных среднем по 5-слойной CV повышает ROC AUC ≥ +0.005 и Δ негативных побочных метрик ≤ 0.002»).
- Адаптация под модель_type (например: для деревьев менее важна масштабировка; для линейных моделей важна стандартизация и слабая корреляция между признаками).
- Тесты на устойчивость и переобучение (validation on temporal holdout, test leakage checks, evaluation on different slices).
9) План итераций и приоритеты внедрения
- Краткий roadmap: какие признаки внедрять первыми, какие подождать, какие требуют A/B/online тестирования.
- Пример расписания (микро-планы: разработка → локальное тестирование → CV → holdout → prod).
10) Примеры кода (минимум один пример) и чек-лист для инженера данных
- Малый reproducible snippet (pandas/sklearn/LightGBM/SQL) для одного типичного признака + pipeline препроцессинга.
- Контрольный список для деплоя признака.
11) Краткое резюме выводов и следующих шагов (3–5 пунктов).
Формат ответа: строгий, структурированный документ; для каждого предложенного признака и для каждого шага валидации используйте подзаголовки и буллеты. Не обозначайте шаги как "возможно" без явного указания степени уверенности. Если информация недостаточна, чётко укажите, какие допущения использованы.
