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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка рабочих процессов агента

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

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

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

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

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

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

С точки зрения инструментов рассмотрим пакет SDK для оценки ИИ Azure, который поддерживает такие проверки:

• Разрешение намерений: правильно ли агент или оркестратор понимают запрос пользователя?
• Точность вызова средства: вызываются ли правильные инструменты с правильными параметрами?
• Соблюдение задач: соответствуют ли окончательные выходные данные назначенной задаче и предварительным указаниям?

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

Тестирование аспектов безопасности

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

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

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

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

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

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

Тестирование детерминированного поведения

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

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

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

Конечные точки вывода предоставляют созданные модели через ИНТЕРФЕЙСы REST API и должны тестироваться за рамки простой точности модели. Независимо от того, используете ли вы платформы PaaS или локальные серверы, проверьте конечную точку, как и любую другую конечную точку, чтобы обеспечить надежность, масштабируемость и безопасность.

• Функциональное и интеграциочное тестирование. Проверьте обработку запросов, структуру ответа и интеграцию с другими компонентами.

• Производительность и нагрузочное тестирование. Имитируйте реалистичные условия для оценки пропускной способности, задержки и использования ресурсов. Для конечных точек вывода PaaS сосредоточьтесь на метриках уровня маркеров (токены/с или токены/мин), которые более значимы, чем традиционные размеры запросов REST API.

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

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

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

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

Тестирование рабочего процесса обработки данных приземления

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

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

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

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

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

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

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

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

Руководство по тестированию обучения модели и тонкой настройки

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

Оценка модели

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

Дополнительные сведения см. в разделе "Регрессия/ прогнозирование метрик".

Данные для оценки и тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Средства тестирования

Рассмотрим следующие ресурсы Azure:

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

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

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