Тестирование для LUIS DevOps

  • Статья

Внимание

LUIS будет прекращена 1 октября 2025 г. и с 1 апреля 2023 г. вы не сможете создать новые ресурсы LUIS. Мы рекомендуем перенести приложения LUIS в понимание общения, чтобы воспользоваться продолжением поддержки продуктов и многоязычными возможностями.

Следуя этим рекомендациям, инженеры ПО, разрабатывающие приложение Language Understanding (LUIS), могут применять методы DevOps в отношении системы управления версиями, автоматизированных сборок, тестирования и управления выпусками.

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

Тесты являются важной частью рабочих процессов CI/CD. Когда изменения в приложении LUIS предлагаются в запросе на вытягивание (PR) или после того, как изменения объединены в вашу основную ветвь, рабочие процессы CI должны запускать тесты, чтобы убедиться, что обновления не вызвали каких-либо регрессий.

Как проводить модульное и пакетное тестирование

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

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

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

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

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

Написание тестов

При написании набора тестов, для каждого теста вам нужно определить:

  • Тестовая фраза
  • Ожидаемое намерение
  • Ожидаемые объекты.

Используйте синтаксис пакетного файла LUIS, чтобы определить группу тестов в файле в формате JSON. Например:

[
  {
    "text": "example utterance goes here",
    "intent": "intent name goes here",
    "entities":
    [
        {
            "entity": "entity name 1 goes here",
            "startPos": 14,
            "endPos": 23
        },
        {
            "entity": "entity name 2 goes here",
            "startPos": 14,
            "endPos": 23
        }
    ]
  }
]

Некоторые инструменты тестирования, такие как NLU.DevOps, также поддерживают тестовые файлы в формате LUDown.

Разработка модульных тестов

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

В каждом модульном тесте для данного тестового речевого фрагмента вы можете:

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

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

Совет

Инструмент NLU.DevOps поддерживает все ваши потребности в тестировании LUIS. Команда compare при использовании в режиме модульного тестирования будет утверждать, что все тесты пройдены, и игнорировать ложноположительные результаты для объектов, которые не отмечены в перечне ожидаемых результатах.

Разработка пакетных тестов

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

Выполнение тестов

Портал LUIS предлагает функции, помогающие в интерактивном тестировании:

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

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

Выполнение тестов в автоматизированном рабочем процессе сборки

Функции интерактивного тестирования на портале LUIS полезны, но для DevOps автоматическое тестирование, выполняемое в рабочем процессе CI/CD, предъявляет определенные требования:

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

LUIS не предлагает инструмент командной строки или высокоуровневый API, который предлагает указанные функции. Мы рекомендуем использовать инструмент NLU.DevOps для запуска тестов и проверки результатов как в командной строке, так и во время проведения автоматического тестирования в контексте рабочего процесса CI/CD.

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

Совет

  • Если вы реализуете собственное решение для тестирования и пишете код для отправки тестовых сообщений на конечную точку, помните, что если вы используете ключ разработки LUIS, допустимая скорость транзакций ограничена 5TPS. Либо ограничьте скорость отправки, либо используйте вместо этого ключ прогнозирования.
  • При отправке тестовых запросов в конечную точку не забудьте использовать log=false в строке запроса вашего прогнозного запроса. Это гарантирует, что ваши тестовые высказывания не будут зарегистрированы LUIS и попадут в список просмотра речевых фрагментов конечной точки, представленный функцией активного обучения LUIS, и в результате случайно будут добавлены к обучающим речевым фрагментам вашего приложения.

Запуск модульных тестов из командной строки и в рабочих процессах CI/CD

Вы можете использовать пакет NLU.DevOps для запуска тестов из командной строки:

  • Используйте test command NLU.DevOps, чтобы отправить тесты из тестового файла в конечную точку и записать фактические результаты прогнозов в файл.
  • Используйте команду NLU.DevOps compare, чтобы сравнить фактические результаты с ожидаемыми результатами, определенными во входном тестовом файле. Команда compare генерирует выходные данные теста NUnit и при использовании в режиме модульного тестирования с использованием флага --unit-test будет подтверждать, что все тесты пройдены.

Запуск пакетных тестов из командной строки и в рабочих процессах CI/CD

Вы также можете использовать пакет NLU.DevOps для запуска пакетных тестов из командной строки.

  • Используйте команду NLU.DevOps test, чтобы отправить тесты из тестового файла в конечную точку и записать фактические результаты прогнозов в файл, как и в случае модульных тестов.
  • Используйте команду NLU.DevOps compare в режиме тестирования производительности, чтобы измерить производительность вашего приложения. Вы также можете сравнить производительность вашего приложения с базовым тестом производительности, например, с результатами, полученными от момента последней фиксации к основному или текущему выпуску. В режиме тестирования производительности команда compare генерирует выходные данные теста NUnit и результаты пакетного тестирования в формате JSON.

Недетерминированное обучение LUIS и влияние на проведение тестирование

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

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

Если вы хотите отключить недетерминированное обучение для тех версий приложения LUIS, которые вы создаете с целью тестирования, используйте API-настроек версии с параметром UseAllTrainingData, установленным на true.

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