Справочник

Требуется централизованная, совместно используемая платформа для всего жизненного цикла машинного обучения, от подготовки данных до развертывания и мониторинга.

→Рабочая область Машинного обучения Azure.

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

Источник↗

Требуется, чтобы весь трафик рабочей области ML, включая трафик к зависимым ресурсам, таким как Storage и ACR, оставался в частной сети Azure и не был доступен из общедоступного Интернета.

→Настройте рабочую область Машинного обучения Azure с управляемой виртуальной сетью и используйте приватные конечные точки для рабочей области и всех ее зависимых ресурсов (Storage, Key Vault, ACR).

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

Источник↗

Решение ML должно соответствовать строгим правилам резидентности данных, гарантируя, что все данные и вычисления остаются в пределах определенного географического региона (например, Европейского союза).

→Создайте рабочую область Машинного обучения Azure, все связанные учетные записи хранения и вычислительные ресурсы в регионе в пределах требуемой географической области. Используйте сетевую изоляцию для предотвращения утечки данных.

Почему: Ресурсы Azure привязаны к региону, в котором они созданы. Это обеспечивает соответствие требованиям к физическому расположению данных. Сетевая изоляция (управляемая виртуальная сеть) предотвращает обработку данных за пределами этой границы.

Обеспечение соблюдения организационных стандартов во всех рабочих областях ML, например, требование тегов для распределения затрат, ограничение размеров виртуальных машин или обязательная отправка диагностических журналов.

→Используйте Azure Policy для применения и принудительного соблюдения правил создания и настройки ресурсов.

Почему: Azure Policy обеспечивает масштабируемое, централизованное управление. Она предотвращает создание несоответствующих ресурсов, обеспечивая соблюдение единых стандартов без ручного надзора.

Источник↗

Доступ к данным в Azure Storage из рабочей области ML без сохранения учетных данных (ключей учетных записей, токенов SAS) в коде или конфигурации.

→Создайте подключение к хранилищу данных с использованием аутентификации на основе удостоверений. Предоставьте управляемому удостоверению рабочей области (или удостоверению пользователя/вычислительной среды) соответствующую роль RBAC (например, "Читатель данных больших двоичных объектов хранилища") в учетной записи хранения.

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

Несколько команд работают над проектами с различными уровнями безопасности (например, PII против анонимизированных данных). Необходимо обеспечить изоляцию ресурсов.

→Создайте отдельные рабочие области Машинного обучения Azure для каждой границы безопасности. Рабочая область для проектов PII должна иметь более строгую сетевую изоляцию, чем для нечувствительных проектов.

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

Необходимо отделить деятельность по разработке/экспериментированию от производственного обучения и развертывания моделей, чтобы предотвратить помехи и обеспечить стабильность.

→Используйте отдельные рабочие области Машинного обучения Azure для сред разработки и производства.

Почему: Это изолирует производственные ресурсы, данные и модели от экспериментальной работы, обеспечивая стабильность и четкое управление для производственных конвейеров MLOps.

Предоставьте вычислительные ресурсы для периодически запускающихся задач обучения ML с высоким приоритетом на минимизацию затрат.

→Используйте вычислительный кластер Машинного обучения Azure с виртуальными машинами с низким приоритетом, минимальным количеством узлов 0 и настроенным автомасштабированием.

Почему: Виртуальные машины с низким приоритетом обеспечивают значительную экономию средств для прерываемых рабочих нагрузок. Минимум 0 узлов гарантирует, что вы ничего не платите, когда кластер простаивает.

Источник↗

Необходимо предоставить вычислительные ресурсы как для интерактивной разработки в Jupyter-ноутбуках отдельными специалистами по данным, так и для запуска более крупных, автоматических задач обучения.

→Предоставьте вычислительные экземпляры (Compute Instances) для интерактивной разработки (по одному на пользователя). Предоставьте вычислительные кластеры (Compute Clusters) для пакетных задач обучения.

Почему: Вычислительные экземпляры — это однопользовательские, постоянные виртуальные машины, оптимизированные для интерактивной работы. Вычислительные кластеры — это автоматически масштабируемые, многоузловые ресурсы, оптимизированные для пакетных задач.

Убедитесь, что запуски обучения ML воспроизводимы, путем захвата всех программных зависимостей, включая конкретные версии пакетов Python.

→Определите среду Машинного обучения Azure, используя YAML-файл среды conda или Dockerfile. Зарегистрируйте и версионируйте эту среду для использования в задачах обучения.

Почему: Среды — это версионируемые, многократно используемые спецификации среды выполнения. Это отделяет среду от вычислительных ресурсов, гарантируя, что любой запуск с этой версией среды будет идентичным.

Логика Feature engineering должна быть согласованной между обучением и выводом, а признаки должны быть многократно используемыми для нескольких моделей и команд.

→Используйте управляемый магазин признаков (Managed Feature Store) Машинного обучения Azure для определения, вычисления и обслуживания признаков.

Почему: Магазин признаков обеспечивает согласованность (предотвращая расхождение между обучением и обслуживанием), позволяет обнаруживать и повторно использовать признаки, а также предоставляет как автономное (для обучения), так и интерактивное (для вывода с низкой задержкой) хранение.

Систематически отслеживайте все эксперименты ML, включая версии кода, гиперпараметры, метрики и артефакты модели, для сравнения и воспроизводимости.

→Используйте MLflow, который нативно интегрирован в Машинное обучение Azure. Включите автологирование или используйте явные команды `mlflow.log_*` в сценарии обучения.

Почему: MLflow предоставляет стандартизированную, открытую платформу для отслеживания экспериментов. Машинное обучение Azure выступает в качестве управляемого сервера отслеживания MLflow, предоставляя пользовательский интерфейс для сравнения запусков.

Источник↗

Обучение модели классификации на наборе данных с серьезным дисбалансом классов (например, обнаружение мошенничества), что приводит к низкой производительности для миноритарного класса.

→Примените такие методы, как SMOTE (Synthetic Minority Over-sampling Technique), к обучающим данным. Оцените модель, используя метрики, нечувствительные к дисбалансу, такие как Precision-Recall AUC или F1-score.

Почему: Простое использование точности вводит в заблуждение. SMOTE создает синтетические миноритарные образцы, чтобы помочь модели учиться, а PR-AUC/F1-score корректно измеряют производительность для положительного класса.

Необходимо найти оптимальные гиперпараметры для модели с длительным временем обучения и ограниченным вычислительным бюджетом.

→Используйте задание развертки (sweep job) с байесовской выборкой и политикой раннего завершения (например, Bandit или Median Stopping).

Почему: Байесовская выборка интеллектуально исследует пространство поиска, концентрируясь на перспективных областях. Раннее завершение останавливает плохо работающие запуски раньше, экономя значительное время вычислений и затраты.

Создайте модель прогнозирования временных рядов с использованием AutoML.

→Настройте задание AutoML с `task='forecasting'`, укажите `time_column_name` и установите `forecast_horizon`.

Почему: Указание задачи как "прогнозирование" позволяет AutoML применять специфические для временных рядов методы, такие как генерация признаков отставания, обнаружение сезонности и перекрестная проверка с учетом времени.

Обучите большую модель глубокого обучения на нескольких графических процессорах на нескольких вычислительных узлах, чтобы сократить время обучения.

→Используйте вычислительный кластер с узлами, поддерживающими GPU. В задании команды настройте свойство `distribution` (например, `type: "PyTorch"`, `process_count_per_instance: <количество GPU>`).

Почему: Машинное обучение Azure упрощает распределенное обучение, управляя настройкой узлов и связью. Конфигурация `distribution` сообщает Машинному обучению Azure, как запускать распределенные процессы обучения.

Источник↗

Автоматизируйте многоступенчатый рабочий процесс ML (например, подготовка данных, обучение, оценка), который может быть повторно использован с различными параметрами.

→Определите конвейер Машинного обучения Azure, используя компоненты для каждого шага. Используйте входы конвейера для параметризации рабочего процесса.

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

Модель очень хорошо работает на обучающем наборе, но плохо на проверочном наборе, что указывается расходящимися кривыми потерь обучения и валидации.

→Это классический признак переобучения. Смягчите его, применяя регуляризацию (например, dropout, L2), используя аугментацию данных, реализуя раннюю остановку или уменьшая сложность модели.

Почему: Разрыв между производительностью обучения и валидации показывает, что модель запомнила обучающие данные вместо обобщения. Методы регуляризации наказывают за сложность для улучшения обобщения.

Длительно выполняющаяся задача обучения на виртуальных машинах с низким приоритетом (spot) рискует быть прерванной и потерять прогресс.

→Реализуйте контрольные точки в сценарии обучения для периодического сохранения состояния модели и оптимизатора в каталог `./outputs`.

Почему: Каталог `./outputs` автоматически сохраняется Машинным обучением Azure. Сохранение контрольных точек позволяет возобновить работу с последнего сохраненного состояния после прерывания, сохраняя прогресс и экономя затраты.

В организации действует политика, согласно которой в производственной среде могут использоваться только определенные алгоритмы ML. Необходимо обеспечить соблюдение этого во время выполнения AutoML.

→В конфигурации AutoML используйте параметр `blocked_models`, чтобы явно исключить неутвержденные алгоритмы из пространства поиска.

Почему: Это обеспечивает прямой, принудительный способ согласования AutoML с политиками управления, предотвращая выбор несовместимых моделей.

Разверните модель для прогнозирования в реальном времени с низкой задержкой (<100 мс) и высокой доступностью.

→Разверните модель в управляемой онлайн-конечной точке Машинного обучения Azure.

Почему: Управляемые онлайн-конечные точки — это полностью управляемая служба, оптимизированная для вывода в реальном времени, предоставляющая автомасштабирование, балансировку нагрузки, сине-зеленые развертывания и встроенный мониторинг.

Источник↗

Оцените большой объем данных (миллионы записей) асинхронно, при этом приоритетом является экономическая эффективность.

→Разверните модель в пакетной конечной точке Машинного обучения Azure.

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

Разверните новую версию модели, минимизируя риски. Необходимо постепенно перенаправлять трафик на новую версию и обеспечивать легкий откат.

→Используйте одну управляемую онлайн-конечную точку с двумя развертываниями (например, "синее" для старой модели, "зеленое" для новой). Используйте разделение трафика для контроля процента запросов, поступающих на каждое развертывание.

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

Упакуйте модель с ее зависимостями и артефактами стандартизированным, независимым от фреймворка способом для развертывания.

→Используйте формат модели MLflow. При регистрации модели включите файл conda.yaml или requirements.txt и любые необходимые артефакты кода.

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

Развернутая модель имеет высокую задержку, потому что она загружает большие вспомогательные файлы (например, большой featurizer) при каждом запросе на прогнозирование.

→Переместите логику загрузки файлов из функции `run()` в функцию `init()` в сценарии оценки.

Почему: Функция `init()` запускается только один раз при запуске контейнера. Загрузка ресурсов здесь делает их глобально доступными для всех вызовов `run()`, избегая избыточной загрузки при каждом запросе.

Конечная точка реального времени испытывает переменный трафик (высокие пики, низкие спады). Необходимо поддерживать производительность экономически эффективным способом.

→Настройте автомасштабирование для развертывания управляемой онлайн-конечной точки. Установите минимальное и максимальное количество экземпляров и определите правило масштабирования на основе использования ЦП или задержки запроса.

Почему: Автомасштабирование автоматически регулирует количество вычислительных экземпляров в соответствии с нагрузкой трафика, обеспечивая производительность во время пиков и экономя затраты во время спадов.

Развертывание модели требует специальных системных библиотек, пользовательских версий CUDA или пользовательского сервера вывода, отсутствующих в стандартных образах Машинного обучения Azure.

→Создайте пользовательский Dockerfile, который расширяет базовый образ вывода Машинного обучения Azure, добавьте необходимые зависимости, соберите его и отправьте в Azure Container Registry. Сошлитесь на этот образ в среде развертывания.

Почему: Расширение базового образа обеспечивает полный контроль над средой выполнения, сохраняя совместимость с инфраструктурой обслуживания Машинного обучения Azure.

Автоматизируйте сквозной жизненный цикл ML, включая переобучение, оценку и развертывание, запускаемый изменениями в коде или данных.

→Используйте Azure DevOps или GitHub Actions, интегрированные с Azure ML CLI v2, для создания конвейера CI/CD. Конвейер должен включать шлюз качества, который сравнивает новую модель с базовой перед развертыванием.

Почему: Этот паттерн MLOps автоматизирует рабочий процесс ML, обеспечивая согласованность, качество и быструю итерацию. Шлюз качества предотвращает регрессии производительности модели.

Производительность производственной модели снижается из-за изменений в распределении входных данных. Модель необходимо автоматически переобучать при обнаружении значительного дрейфа.

→Настройте монитор дрейфа данных Машинного обучения Azure на конечной точке. Настройте оповещение, которое запускает Azure Logic App или Azure Function, что, в свою очередь, запускает конвейер переобучения.

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

Новая развернутая версия модели оказалась неисправной в производственной среде. Необходимо быстро вернуться к предыдущей стабильной версии.

→При использовании сине-зеленого развертывания перенаправьте 100% трафика обратно на стабильное развертывание. В качестве альтернативы обновите конечную точку, чтобы повторно развернуть предыдущую версию модели из реестра моделей.

Почему: Переключение трафика обеспечивает мгновенный откат. Повторное развертывание версии из реестра также является быстрым и надежным способом восстановления известного рабочего состояния.

Необходимо отслеживать как рабочее состояние (задержка, ошибки), так и предсказательное качество (дрейф данных, точность) развернутой модели.

→Включите интеграцию Application Insights на конечной точке для операционных метрик. Настройте сбор данных и мониторинг дрейфа данных Машинного обучения Azure для метрик качества модели.

Почему: Этот двухсторонний подход обеспечивает полное представление о состоянии модели. App Insights отслеживает производительность системы, в то время как сбор данных/мониторинг дрейфа отслеживает предсказательную производительность модели.

Конечная точка модели не работает из-за некорректных или неожиданных входных данных от клиентов.

→Реализуйте логику проверки входных данных в функции `run()` сценария оценки. Проверяйте типы данных, диапазоны и структуры и возвращайте содержательную ошибку (например, HTTP 400) для недействительных запросов.

Почему: Проверка на стороне сервера защищает модель от сбоев и предоставляет четкую, немедленную обратную связь потребителям API, делая службу более надежной.

Необходимо понять, почему сложная модель "черного ящика" делает определенные прогнозы, для отладки, соответствия требованиям или доверия заинтересованных сторон.

→Используйте панель инструментов Ответственного ИИ в Машинном обучении Azure для генерации объяснений модели. Используйте SHAP для локальных объяснений (отдельных прогнозов) и глобальной важности признаков для общего поведения модели.

Почему: Значения SHAP предоставляют надежный, независимый от модели способ определения влияния каждого признака на конкретное предсказание, что крайне важно для регуляторных сценариев и отладки.

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

→Используйте оценку справедливости панели инструментов Ответственного ИИ для анализа метрик справедливости (например, демографическое равенство, равные шансы) по чувствительным признакам. Примените методы смягчения, такие как корректировка пороговых значений после обработки, если обнаружены расхождения.

Почему: Оценка справедливости предоставляет количественные доказательства поведения модели в разных группах. Методы смягчения помогают исправить предубеждения для обеспечения справедливых результатов.

LLM должна отвечать на вопросы на основе конкретных, частных документов компании, не выдумывая факты.

→Реализуйте паттерн Retrieval-Augmented Generation (RAG). Используйте Azure AI Search для создания векторного индекса документов. Во время запроса извлекайте релевантные фрагменты документов и передавайте их LLM в качестве контекста в запросе.

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

LLM должна постоянно следовать определенным указаниям, тону и форматам вывода (например, генерировать JSON).

→Используйте подробный инжиниринг системных запросов. Предоставьте четкую персону, явные правила и ограничения, а также примеры желаемых пар входных/выходных данных для нескольких выборок (few-shot examples).

Почему: Хорошо составленный системный запрос является наиболее прямым и эффективным способом управления поведением LLM без затрат и сложности тонкой настройки.

Необходимо измерить качество приложения LLM на основе RAG.

→Используйте метрики оценки, специфичные для RAG, такие как Groundedness (подтвержден ли ответ контекстом?) и Relevance (отвечает ли ответ на вопрос пользователя?).

Почему: Стандартные метрики NLP, такие как ROUGE, недостаточны. Groundedness и Relevance непосредственно измеряют основные проблемы RAG: предотвращение галлюцинаций и предоставление полезных ответов.

Приложение LLM слишком медленное или дорогое для использования в производственной среде.

→Внедрите маршрутизатор для использования меньших, более дешевых моделей (например, GPT-3.5-Turbo) для простых задач. Включите кэширование ответов для повторяющихся запросов. Оптимизируйте длину запроса.

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

Приложение LLM обрабатывает конфиденциальные данные, которые не должны покидать корпоративную сеть или использоваться для обучения модели.

→Разверните службу Azure OpenAI с приватной конечной точкой. Настройте ресурс так, чтобы он не регистрировал данные запросов/завершений.

Почему: Приватные конечные точки обеспечивают сетевую изоляцию. Опция без логирования предоставляет дополнительный уровень конфиденциальности данных, соответствуя строгим требованиям соответствия.

Поток запросов (prompt flow), разработанный в Azure AI Studio, необходимо развернуть в качестве высокодоступной, масштабируемой производственной конечной точки.

→Разверните поток запросов в качестве управляемой онлайн-конечной точки Машинного обучения Azure.

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

Пользовательское приложение генеративного ИИ должно быть защищено от генерации или обработки вредоносного, оскорбительного или небезопасного контента.

→Используйте как встроенные фильтры контента Azure OpenAI, так и службу Azure AI Content Safety для глубокой модерации как запросов, так и завершений.

Почему: Многоуровневая безопасность критически важна. Встроенные фильтры обеспечивают базовый уровень, в то время как специализированная служба Content Safety предлагает более детальный контроль и мультимодальные возможности.

Чат-бот с разговорным ИИ должен поддерживать контекст на протяжении нескольких обращений пользователя.

→LLM являются без сохранения состояния. Приложение должно управлять историей разговора (например, в сессии или базе данных) и включать соответствующие части истории в каждый новый запрос к LLM.

Почему: Явное предоставление контекста в каждом вызове API — единственный способ для без сохранения состояния LLM "запомнить" разговор.

Необходимо систематически тестировать различные запросы, чтобы найти тот, который обеспечивает наилучшую производительность LLM.

→Используйте Variants в потоке запросов (prompt flow). Определите несколько версий запросов для узла и запустите массовое тестирование на оценочном наборе данных для сравнения метрик производительности.

Почему: Variants обеспечивают структурированный, основанный на данных подход к инжинирингу запросов, переходя от ручного метода проб и ошибок к систематической оптимизации.

Необходимо отслеживать производственное приложение LLM как на предмет операционного состояния, так и на предмет качества ответов.

→Объедините Application Insights для операционной телеметрии (задержка, частота ошибок, использование токенов) с периодическими заданиями пакетной оценки, используя поток оценки для анализа качества ответов (groundedness, relevance).

Почему: Мониторинг LLM требует отслеживания как производительности системы, так и качества сгенерированного контента. Эта комбинация обеспечивает целостное представление о состоянии приложения.