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


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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка и проверка модели
Проверьте конечную точку вывода. Проводите нагрузочное тестирование на конечной точке, которую хостит ваш сервер вывода, и выберите конфигурации 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 Machine Learning, которые также требуют ресурсов памяти и сетевых ресурсов. Мы рекомендуем нагрузочное тестирование на этапе разработки, чтобы оценить потребности вычислений и убедиться, что предлагаемые номера 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 Load Testing хорошо подходит для нагрузочного тестирования и может генерировать высокую нагрузку объема. Другие варианты с открытым кодом, такие как Apache JMeter, также популярны. Рассмотрите возможность вызова этих тестов непосредственно из вашей среды. Например, Машинное обучение хорошо интегрируется с нагрузочном тестировании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Внедрить инструменты

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

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

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