|
часть кода легко протестировать с помощью традиционного модульного тестирова
ния. И хотя может показаться, что добавление слоя бизнеслогики до (или после)
МОпредиктора — просто лишний труд, оно предоставляет точки доступа для при
нудительной коррекции предсказаний. Кроме того, именно там можно добавить
мониторинг или журналирование, которые явно понадобятся, когда вашу утилиту
начнут использовать более широко. После этого вступления по очереди рассмотрим
три основные причины для использования «золотых значений».
Подобные тесты на основе «золотых значений» часто применяют для сквозного
тестирования системы — для проверки того, что выдаст система, получив на вхо
де необработанные входные данные. При этом система МО обучается, через код
обычной последовательности операций конечного пользователя запрашивается
предсказание, и ответ возвращается пользователю. Все аналогично модульному
тестированию из листинга 12.1, но система машинного обучения работает в связке
с остальным приложением. Можно написать аналогичный листингу 12.1 тест, для
которого фактический результат предсказания не будет важен, и на самом деле такой
Глава 12. Тестирование, оптимизация и развертывание моделей
483
тест будет надежнее. Однако очень заманчиво и логично будет связать его с парой
пример «данных/предсказание», чтобы разработчики, возвращаясь к этому тесту
позднее, сразу все понимали.
Здесь и начинаются проблемы — нам нужен пример данных, предсказание для
которого известно и должно быть правильно, иначе сквозной тест не будет пройден.
Поэтому мы добавим менее масштабный тест для проверки этого предсказания
на части охватываемого сквозным тестом конвейера. Теперь, если сквозной тест
не пройден, а этот меньший тест пройден успешно, можно будет ограничить поле
поиска ошибки взаимодействиями между основной моделью машинного обучения
и остальными частями конвейера (например, кодом ввода/обработки данных или
постобработки). Если же оба теста не пройдены, значит, нарушен инвариант «при
мер/предсказание». В этом случае ценность тестов скорее диагностическая, но имеет
смысл при таком двойном непрохождении тестов выбрать новый пример данных для
кодирования, а не обучать всю модель заново.
Еще один распространенный источник тестирования на основе «золотых значе
ний» — различные бизнестребования. Допустим, безошибочность для какоголибо
легко определимого подмножества примеров данных должна быть выше, чем для
остальных. В этом случае, как уже упоминалось ранее, имеет смысл добавить перед
или после модели слой бизнеслогики для обработки подобных примеров. Впро
чем, можете поэкспериментировать с
заданием весов для примеров данных
(example
weighting), при котором некоторые примеры считаются важнее прочих при вычисле
нии общих метрик качества работы модели. Что не гарантирует правильность работы
модели в целом, но подталкивает модель в сторону более точных результатов для
этих примеров. Если реализация такого слоя бизнеслогики доставляет трудности,
поскольку не получается легко заранее определить, какие свойства входных данных
приводят к этим особым случаям, может понадобиться воспользоваться второй мо
делью, которая нужна лишь для того, чтобы понять, требуется ли принудительная
коррекция. В этом случае применяется ансамбль моделей, а бизнеслогика выбирает
нужное действие на основе сочетания предсказаний от двух слоев.
Последний из случаев — получение от пользователя сообщения о программной
ошибке с примером данных, на котором модель выдает неправильный результат. Если
он неправилен, исходя из бизнестребований, мы возвращаемся к предыдущему сце
нарию. Если же он просто попадает в процент ошибок кривой эффективности модели,
мы мало что можем сделать. Все в пределах приемлемой эффективности обученного
алгоритма; какоето количество ошибок бывает у всех моделей. Можно разве что до
бавить пару «пример данных/правильное предсказание» в обучающий/проверочный/
контрольный набор данных по ситуации в надежде сгенерировать в будущем лучшую
модель, но использовать «золотые значения» для модульного тестирования не следует.
Единственное исключение: если модель неизменна — весовые коэффициенты мо
дели и ее архитектура внесены в систему контроля версий и не обновляются в тестах.
Тогда вполне уместно использовать «золотые значения» для тестирования выходных
сигналов основанной на модели системы вывода, поскольку ни модель, ни примеры
данных не подвергаются изменениям. Подобная система вывода включает не только
модель, а и, например, части, отвечающие за предварительную обработку входных
484
Do'stlaringiz bilan baham: |
