Поделиться через

Тестирование и оценка рабочих нагрузок ИИ в Azure

  • Статья

Целью тестирования в рабочих нагрузках ИИ является обеспечение качества при внедрении изменений в систему. Тестирование может проверить, соответствует ли рабочая нагрузка идентифицированным целевым объектам и соответствует ли ей ожидания пользователей. Это также предотвращает регрессию качества. Этот процесс включает проведение тестов в различных функциональных областях и оценку качества функциональности, обработки нагрузки, прогнозируемости и других критериев на основе требований к рабочей нагрузке.

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

Платформа Azure Well-Architected Framework описывает комплексную методологию тестирования. Следует использовать различные типы тестов на разных этапах жизненного цикла разработки и между различными системными компонентами и потоками. Без этих тестов развернутые изменения могут снизить качество системы. Например, незначительные ошибки кода могут стать большими сбоями системы. Поведение системы может стать непредсказуемым или привести к предвзятым результатам из-за недетерминированной природы систем искусственного интеллекта. Кроме того, распределение ресурсов может оказаться неэффективным, а реальные данные пользователя или системные ресурсы могут быть использованы, так как эти системы уязвимы для злоупотреблений.

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

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

Эта статья посвящена применению этой методологии к аспектам ИИ архитектуры. Как проводить эти тесты не в области.

Рекомендации

Ниже приведена сводка рекомендаций, приведенных в этой статье.

Рекомендация Description
Определите метрики успеха для стратегии тестирования. Как и любой другой тип тестирования рабочей нагрузки, необходимо записать и проанализировать соответствующие метрики для данного теста, чтобы убедиться, что тест предоставляет полезные сведения о рабочей нагрузке ИИ.

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

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

▪ Тестирование рабочего процесса обучения
Оцените и проверьте модель, чтобы избежать дублирования в обучающих, оценках и тестировании данных. Чтобы гарантировать, что исходные данные не полностью используются для обучения, необходимо зарезервировать уникальные данные для оценки модели и окончательного тестирования. Эти подмножества не включаются в фактический процесс обучения.

▪ Оценка и проверка модели
Проверьте конечную точку вывода. Проводите нагрузочное тестирование на конечной точке, на которую размещается сервер вывода, и выберите номера SKU GPU на основе этих результатов теста. Для платформы как службы (PaaS) размещенных конечных точек, пропускной способности тестирования и потенциальных сбоев. Эти конечные точки доступны, поэтому проводите надлежащее тестирование безопасности, чтобы предотвратить нарушения тюрьмы.

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

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

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

▪ Предотвращение распада модели

Определение метрик успешности

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

  • Точность представляет отношение правильно прогнозируемых экземпляров к общим экземплярам в тестовом наборе данных. Это распространенная мера общей производительности модели.

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

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

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

Примечание.

При определении метрик успешности для моделей регрессии рекомендуется добавить следующие метрики:

  • Средняя абсолютная ошибка (MAE) измеряет среднее абсолютное различие между прогнозируемыми значениями и фактическими значениями. Вычислите его, принимая среднее значение абсолютных различий между каждым фактическим значением и соответствующим прогнозируемым значением. MAE менее чувствительны к выскользам по сравнению с MSE и RMSE.

  • Средняя квадратная ошибка (MSE) измеряет среднее квадратное различие между фактическими значениями и прогнозируемыми значениями. Вычислите его, принимая среднее значение квадратных различий между каждым фактическим значением и соответствующим прогнозируемым значением. MSE наказывает более крупные ошибки более сильно, чем MAE, потому что ошибки квадратные.

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

Тестирование приема данных

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

Тестирование должно быть интегрировано на протяжении жизненного цикла, включая этапы проектирования, разработки и производства.

Тестирование для упрощения выбора конструктора

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

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

В сценариях, в которых вы включаете ИИ в существующую архитектуру, проверьте, насколько хорошо новая технология может интегрироваться с текущей системой.

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

Проверка качества кода

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

Выполняйте тесты как часть конвейера непрерывной интеграции и непрерывной доставки.

Тестирование в динамической системе

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

  • Выполните запланированные тесты, чтобы убедиться в том, что правильный объем данных был собран, если данные будут приема в заданном расписании с ожидаемым объемом.

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

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

Другим способом проверки правильности системы ETL в рабочей среде является искусственное тестирование. Наличие известных тестовых данных, доступных в рабочей среде, является высокоэффективным. Его можно использовать для проверки сквозной обработки, сравнивая известное начальное состояние с ожидаемым конечным состоянием для данных. Например, документ требуется для анализа документов и хранения персональных данных. Внедрение искусственного документа может проверить, выполняет ли рабочая нагрузка задание манипуляции данными в нужном виде.

Кроме того, экспериментируйте путем выпуска различных интерфейсов, также известных как A/B-тестирование, чтобы узнать о взаимодействии пользователей до полной фиксации. Тестирование A/B помогает предотвратить регрессию качества.

Тестирование данных, собранных во время приема

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

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

В следующем списке приведены некоторые примеры тестовых вариантов:

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

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

  • Проверьте наличие неуместных данных. Прием данных не должен содержать неуместные или ошибочные записи. Процесс приема данных должен отфильтровать эти данные.

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

Проведение стандартных тестов

Важная проблема с приемом данных — это объем данных и пропускной способности. Непрерывная оценка во время операций необходима для предотвращения узких мест производительности. Эта текущая оценка должна быть частью операционных процессов, а не просто однократным тестом. Цель заключается в том, чтобы команда рабочей нагрузки не пропустила свои цели уровня обслуживания.

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

Примечание.

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

Тестирование рабочего процесса обучения

Обучите модель с помощью пользовательского кода, например скриптов PyTorch, которые выполняют фактические учебные работы. Эти скрипты выполняются на вычислительных ресурсах, таких как в записных книжках или Машинное обучение Azure заданиях, которые также требуют памяти и сетевых ресурсов. Мы рекомендуем нагрузочное тестирование на этапе разработки, чтобы оценить потребности вычислений и убедиться, что предлагаемые номера SKU подходят. Часто требуется ручное тестирование, чтобы определить оптимальную конфигурацию для эффективного выполнения рабочей нагрузки в течение ограниченного времени.

Напишите скрипты с помощью специализированных пакетов SDK, которые обрабатывают большую часть задач. Однако, так как скрипты по-прежнему являются кодом, следует интегрировать модульное тестирование в рамках разработки. Эти тесты помогают гарантировать отсутствие регрессии при обновлении зависимостей. Если модульное тестирование невозможно, перед развертыванием нового кода необходимо выполнить ручное тестирование, чтобы предотвратить регрессию качества.

Эти скрипты выполняются как часть рабочего процесса, например Студия машинного обучения Azure, которые могут предоставлять аналитические сведения о том, когда и когда выполняется скрипт. Но рекомендуется выполнять тесты интеграции, чтобы убедиться, что эти скрипты вызываются надежно.

Оценка и проверка модели

Примечание.

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

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

Использование данных для оценки и тестирования

Обычно существует три ключевых набора данных, секционированные из исходных данных: обучение, оценка и тестирование.

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

Все наборы данных должны содержать высококачественные данные, чтобы свести к минимуму шум. Тестовые случаи приема данных и предварительной обработки конвейеров могут служить контрольными точками качества. Отсутствие примеров также может атрибутировать к данным низкого качества. Используйте искусственные данные для балансировки и обеспечения единообразия в наборе данных. Этот подход полезен для моделей обучения, таких как модели обнаружения мошенничества, в которых реальные экземпляры мошенничества редки, что затрудняет получение достаточной статистической мощности для надежных прогнозов.

Чтобы избежать предвзятости прогнозов, следует оставить все наборы данных уникальными. Вы не должны использовать данные обучения для оценки, и не следует использовать данные оценки для тестирования. Резервируйте уникальные данные для оценки модели и окончательного тестирования.

Использование метрик оценки

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

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

Аналогичный подход применяется к моделям сгенерируемым ИИ. Имеют процессы, которые оценивают и вычисляют результаты взаимодействия с пользователем на основе производительности модели. Например, заземление является одной из ключевых метрик, которые квалификируют, насколько хорошо модель соответствует исходным данным. Relevancy — это еще одна важная метрика, указывающая, насколько релевантна реакция на запрос. Примеры метрик см. в разделе "Оценка и мониторинг метрик" для создания искусственного интеллекта.

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

Генерируемый ИИ интегрируется с кодом оркестрации, логикой маршрутизации и индексом для получения дополненного поколения (RAG), что усложняет оценку. Хотя вы должны оценить модели по отдельности с помощью метрик, важно также оценить другие системные компоненты.

Тестирование модели

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

  • Приземление относится к выравниванию модели с исходными данными. Приземленная модель создает ответы, которые соответствуют реальности.

  • Relevancy указывает, насколько релевантн ответ на данный вопрос. Высокий заземленный ответ может не отвечать на релевантность, если он напрямую не отвечает на этот вопрос.

  • Сходство измеряет сходство между текстом исходных данных и созданным ответом. Модель использует точные формулировки? Отсутствие редакционной системы управления может снизить оценку сходства.

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

  • Fluency относится к использованию словаря. Если модель соответствует руководству по стилю и представляет содержимое в соответствующем формате, он может быть свободно даже в том случае, если он не хватает приземления или релевантности.

  • Согласованность оценивает, естественно ли и последовательно потоков речи модели. Он оценивает, чувствует ли разговор как подлинный обмен.

Тестовые гиперпараметры

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

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

Проверка конечной точки вывода

Конечная точка вывода — это REST API, который позволяет получить доступ к моделям для прогнозирования. Это интерфейс, в котором вы отправляете данные в рамках запроса и получаете ответ, содержащий результаты из модели. Конечная точка размещена на вычислительных ресурсах, которые могут быть PaaS, например Azure OpenAI Service или сервер вывода, отличный от Майкрософт, например NVIDIA Triton Inference Server, TorchServe и BentoML. В сценариях PaaS поставщик услуг обрабатывает тестирование в определенной степени. Однако если вы размещаете конечную точку, обработайте ее как любой другой API и тщательно протестируйте ее.

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

Рекомендации по тестированию серверов размещения выводов

Важно понимать характеристики нагрузки вычислений и проверять производительность с помощью нагрузочного тестирования. Эти действия помогают выбирать технологии при разработке или оптимизации архитектуры. Например, разные серверы вывода имеют различные характеристики производительности. Код потребляет циклы ЦП и память по мере увеличения числа одновременных подключений. Узнайте, как код и вычислительные ресурсы выполняются в стандартных и пиковых условиях нагрузки. Нагрузочное тестирование Azure является хорошим вариантом для нагрузочного тестирования и может генерировать высокую нагрузку тома. Другие варианты с открытым кодом, такие как Apache JMeter, также популярны. Рассмотрите возможность вызова этих тестов непосредственно из вашей среды. Например, Машинное обучение хорошо интегрируется с нагрузочном тестировании.

Другим ключевым решением является выбор возможностей GPU. Многие модели требуют gpu для эффективного вывода из-за их проектирования. Нагрузочное тестирование помогает понять ограничения производительности SKU GPU и предотвратить превышение производительности, которые являются важными финансовыми соображениями.

Компромисс. Номера SKU GPU являются дорогостоящими. Хотя вы можете выбрать консервативные варианты в выборе номера SKU, важно постоянно проверять, не используются ли ресурсы GPU и права на них, когда это возможно. После внесения изменений проверьте использование ресурсов для поддержания баланса между эффективностью затрат и оптимизацией производительности. Рекомендации по оптимизации затрат см . в рекомендациях по оптимизации затрат на компоненты.

Для платформ размещения, отличных от PaaS, безопасность имеет решающее значение, так как API предоставляется публично. Важно убедиться, что конечная точка не используется или скомпрометирована, что может поставить под угрозу всю систему. Включите эту конечную точку в рамках обычного тестирования безопасности вместе с другими общедоступными конечными точками. Рассмотрите возможность проведения тестов, таких как тестирование на проникновение, в динамической системе. Другим аспектом безопасности является безопасность содержимого. Код может вызывать специализированные API, которые обнаруживают вредное содержимое в полезных данных запроса и ответа. Безопасность содержимого ИИ Azure может вызываться из тестирования, чтобы упростить тестирование безопасности содержимого.

Основные стратегии см. в рекомендациях по тестированию безопасности.

Рекомендации по тестированию конечных точек вывода PaaS

Клиент должен ожидать ошибок при отправке запросов в конечную точку вывода в службе PaaS. Сбои могут возникать из-за перегрузки системы, безответственных внутренних серверов и других условий ошибки. Проводите анализ режима сбоя в службе и проверьте эти потенциальные сбои. Анализ режима сбоя требуется для разработки и реализации стратегий устранения рисков в клиентском коде. Например, API-интерфейсы Azure OpenAI управляют запросами, возвращая код ответа на ошибку HTTP 429. Клиент должен справиться с этой ошибкой с помощью механизмов повторных попыток и выключателей цепи. Дополнительные сведения см. в рекомендациях по выполнению анализа режима сбоя.

Тестирование служб PaaS поможет вам выбрать номера SKU службы, так как вы понимаете связанные затраты, такие как оплата по мере использования или предварительно подготовленные вычисления. Используйте калькуляторы цен Azure для оценки рабочих нагрузок, частоты и использования маркеров, чтобы определить лучшие варианты выставления счетов и вычислений. Имитируйте рабочие нагрузки с низкими затратами SKU и оправдывают высокопроизводительные варианты, такие как подготовленные единицы пропускной способности (PTUS) для Azure OpenAI.

Нагрузочное тестирование не так актуально для вычислений с оплатой по мере использования, так как с бесконечной емкостью вы не сталкиваетесь с проблемами. Тестирование проверяет ограничения и квоты. Мы не рекомендуем нагрузочное тестирование для вычислений с оплатой по мере использования, так как это значительные финансовые расходы. Однако необходимо нагрузить тест, чтобы проверить пропускную способность, которая измеряется в маркерах в минуту или запросах в минуту. В отличие от стандартных API, которые рассматривают метрики, такие как размер запроса, этот подход оценивает рабочие нагрузки на основе маркеров для определения использования. Ключ заключается в том, чтобы понять количество активных пользователей и измерить пропускную способность соответствующим образом. Дополнительные сведения см. в разделе "Измерение пропускной способности".

Использование элементов управления безопасностью

Независимо от того, используете ли вы сервер вывода или параметр PaaS, безопасность является вашей ответственностью. При использовании конечных точек API важно проверить наличие элементов управления безопасностью и безопасностью содержимого. Убедитесь, что эти элементы управления не могут быть обходить и работать должным образом. Например, отправка известного заблокированного элемента поможет проверить, правильно ли выполняются элементы управления безопасностью и работают правильно перед развертыванием. Рассмотрите возможность выполнения этих тестов по мере необходимости или интеграции их в процесс выпуска.

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

Тестирование данных о заземления

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

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

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

  • Проверьте схему индекса для обеспечения обратной совместимости. Необходимо проверить любое изменение документа или поля, чтобы убедиться, что новая версия по-прежнему может соответствовать предыдущим версиям данных.

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

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

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

  • Необходимо проверить все элементы управления безопасностью. Например, данные могут быть секционированы по отдельным документам. Каждая секция имеет элементы управления доступом. Необходимо правильно протестировать эти элементы управления для защиты конфиденциальности.

Тестирование оркестратора

Ключевым компонентом приложения RAG является центральный оркестратор. Этот код координирует различные задачи, связанные с начальным вопросом пользователя. Для задач оркестратора обычно требуется понимание намерения пользователя, подключение к индексу для поиска данных о заземления и вызов конечной точки вывода. Если агенты должны выполнять задачи, такие как вызов REST API, этот код обрабатывает эти задачи в контексте.

Вы можете разрабатывать код оркестрации на любом языке или писать его с нуля. Однако мы рекомендуем использовать такие технологии, как поток запросов на портале Azure AI Foundry или ациклические графы Apache Airflow (DAG), чтобы ускорить и упростить процесс разработки. Поток запросов предоставляет интерфейс времени разработки. Используйте его для модульной обработки задач в виде единиц и подключения входных и выходных данных каждого блока, в конечном счете формируя код оркестрации, который представляет весь процесс.

Изоляция кода оркестрации. Разработайте его отдельно и разверните его как микрослужбу с веб-конечной точкой и REST API для доступа. Такой подход обеспечивает модульность и простоту развертывания.

С точки зрения тестирования следует рассматривать этот код как любой другой код и проводить модульные тесты. Однако более важным аспектом является его функциональность, например логика маршрутизации, которую можно проверить с помощью функционального и интеграционного тестирования. Проверьте инженерию запроса, чтобы убедиться, что код может обнаруживать намерения пользователей и маршрутизировать вызовы соответствующим образом. Существует несколько платформ и библиотек для тестирования, таких как Scikit-learn, модуль torch.testing PyTorch, FairML для тестирования предвзятости и справедливости, а также анализ модели TensorFlow для оценки модели.

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

Некоторые тесты среды выполнения помогут вам принять решение. Запустите нагрузочные тесты , чтобы понять, как работает этот код под стрессом и использовать результаты для планирования емкости. Так как этот код находится в критической точке архитектуры, где она должна достичь других служб, она может помочь собирать данные телеметрии со всех этих вызовов. Эти данные могут предоставлять аналитические сведения о том, сколько времени тратится на локальную обработку и сетевые вызовы и определяет поведение других компонентов, таких как потенциальная задержка. Такие технологии, как поток запросов, имеют встроенные возможности телеметрии для упрощения этого процесса. В противном случае включите данные телеметрии в пользовательский код.

Примечание.

Тестирование этого кода имеет последствия для затрат. Например, если вы используете Azure OpenAI для размещения конечной точки вывода, стресс-тестирование является распространенной практикой, которая поможет определить ограничения системы. Тем не менее, Плата за Azure OpenAI за каждый звонок, что может сделать обширное стресс-тестирование дорогим. Одним из способов оптимизации расходов является использование неиспользуемых PTUS Azure OpenAI в тестовой среде. Кроме того, можно имитировать конечную точку вывода.

Проблемы безопасности применяются как к коду оркестрации, так и к модели. Включите тестирование для разбиения в тюрьму, где цель состоит в том, чтобы нарушить безопасность модели. Злоумышленники напрямую не взаимодействуют с моделью. Сначала они взаимодействуют с кодом оркестрации. Код оркестрации получает запросы пользователей и анализирует их. Если код оркестрации получает вредоносный запрос, он может пересылать этот запрос в модель и потенциально компрометировать модель.

Безопасность содержимого является еще одним важным аспектом. В приложении чат-бота код оркестрации получает текст чата. В коде рекомендуется вызвать службу безопасности содержимого. Отправьте запрос пользователя и контекст заземления для анализа и получите оценку риска. Экраны запросов — это единый API, который анализирует входные данные большой языковой модели и обнаруживает атаки с запросами пользователей и документированием, которые являются двумя общими типами состязательной входной информации.

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

Предотвращение распада модели

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

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

  • Смещение концепции происходит, когда условия, которые являются внешними для рабочей нагрузки и изменения модели таким образом, чтобы выходные данные модели больше не соответствовали реальности. Например, у вас может быть модель прогноза продаж для продукта технологии. Если конкурент неожиданно вводит более сложный конкурирующий продукт, который привлекает значительное внимание со стороны общественности, необходимо обновить модель на основе изменения тенденций потребителей.

По возможности используйте автоматическое тестирование для обнаружения и оценки распада модели по жизненному циклу модели. Если модель прогнозирует дискретные значения, можно создать тесты для оценки прогнозов с течением времени и измерить отклонение между ожидаемыми и фактическими результатами. Дополните это тестирование мониторингом для обнаружения смещения с течением времени путем сравнения сводной статистики и метрик расстояния.

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

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

Реализация средств

Используйте сборщик данных Машинное обучение Azure, чтобы получить ведение журнала входных и выходных данных из моделей, развернутых в управляемых сетевых конечных точках или веб-конечных точках Kubernetes. Машинное обучение хранит данные вывода в журнале в хранилище BLOB-объектов Azure. Затем эти данные можно использовать для мониторинга моделей, отладки или аудита, что обеспечивает наблюдаемость производительности развернутых моделей. Если вы развертываете модель за пределами Машинное обучение или в Машинное обучение пакетной конечной точке, вы не можете воспользоваться преимуществами сборщика данных и необходимо выполнить другой процесс сбора данных.

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

Следующие шаги

Область разработки: ответственный ИИ