databricks-ml-training

Этот скилл описывает обучение и регистрацию ML-моделей на Databricks с MLflow, Unity Catalog, batch scoring и при необходимости real-time serving. Он предназначен для классификации, регрессии и deep learning с XGBoost, scikit-learn, LightGBM и PyTorch, а также для сценариев с Optuna, custom PyFunc, ResponsesAgent, LangGraph, Unity Catalog Functions, Vector Search и feature engineering. Сначала нужно использовать родительский databricks-core для CLI, аутентификации и выбора профиля. Если требуется жизненный цикл endpoint-а после регистрации модели, соответствующая задача относится к databricks-model-serving, а не к этому скиллу. Ключевое ограничение workflow — обучение должно выполняться в Databricks, обычно в serverless job или notebook, а не в локальном процессе агента. Причина практическая: локальный процесс не имеет доступа к silver-таблицам, MLflow tracking server и Unity Catalog, а его завершение прервёт эксперимент. Для запуска предлагается отправлять job через databricks jobs submit --no-wait. Notebook должен вести эксперимент через MLflow, регистрировать артефакт в Unity Catalog и возвращать структурированный результат через dbutils.notebook.exit. Полезные результаты могут включать версию модели и метрики валидации; вывод print не считается надёжным каналом для serverless one-time run. Канонический путь начинается с silver-таблиц признаков и меток, затем в notebook выполняются исследование данных, обучение с mlflow.autolog, регистрация через MLflow в Unity Catalog и присвоение alias prod. Для подбора гиперпараметров используется Optuna: каждый trial становится дочерним запуском, после чего лучшая конфигурация переобучается и регистрируется. Скилл отдельно предупреждает не включать registered_model_name в autolog для каждого Optuna trial, иначе каждый пробный запуск создаст отдельную версию, а выбор по максимальному номеру не будет означать выбор лучшей модели. Также нужно заранее создать родительскую папку эксперимента: set_experiment не создаёт её автоматически. Способ потребления зависит от задержки и происхождения артефакта. Для пакетной выдачи используется mlflow.pyfunc.spark_udf по alias prod и запись предсказаний в gold-таблицу. Если модель обучалась через feature engineering с training_set, вместо обычного UDF нужен fe.score_batch: он использует зарегистрированную lineage признаков и принимает ключи для автоматического присоединения. Реальное время относится к отдельному serving-процессу и требует собственного управления endpoint-ом. Скилл не обещает, что один шаблон подходит любому набору данных: нужно проверить окно меток, баланс классов, схему таблиц, разрешения Unity Catalog, версию CLI и требования к задержке. Gold-слой остаётся источником истины для чтения, а приложение не должно напрямую запускать модель вместо чтения подготовленных результатов.