Глава 12. Тестирование, оптимизация и развертывание моделей
479
работы модели после успешного обучения и настройки гиперпараметров часто ис
пользуются такие метрики, как степень безошибочности на проверочном наборе
данных. Подобные метрики оценки играют важную роль в мониторинге модели
инженерамилюдьми, но не подходят для автоматического тестирования. Бывает
заманчиво добавить тест для контроля того, что определенная метрика превышает
определенное пороговое значение (например, AUC для задачи бинарной класси
фикации превышает 0,95 или MSE для задачи регрессии — меньше 0,2). Однако
подобные операторы контроля на основе пороговых значений следует использовать
очень осторожно, а то и вообще избегать их, поскольку они очень ненадежны. Про
цесс обучения модели включает несколько источников случайности, в том числе
начальные значения весовых коэффициентов и перетасовку обучающих примеров,
вследствие чего результаты обучения модели различаются от запуска к запуску. Еще
одним источником неустойчивости может быть изменение набора данных (напри
мер, изза регулярного добавления новых данных). Поэтому выбрать подходящее
пороговое значение весьма непросто. При слишком мягком пороговом значении
вы рискуете пропустить реальные проблемы. При слишком жестком — рискуете
столкнуться с большим числом ложных срабатываний.
Отключить случайную составляющую программ TensorFlow.js обычно можно
с помощью вызова функции
Math.seedrandom()
перед созданием и выполнением
модели. Например, следующая строка кода задает конкретное начальное значение
для случайной инициализации весовых коэффициентов, перетасовки данных и слоев
дропаута, так что последующее обучение модели становится детерминированным:
Этот прием очень удобен при написании тестов, включающих операторы контро
ля для значений потерь или метрик.
Однако даже при детерминированном задании начального значения генератора
случайных чисел тестирования одного только
model.fit()
и аналогичных вы
зовов недостаточно для хорошего покрытия тестами кода машинного обучения.
Как и в случае других плохо поддающихся тестированию частей кода, следует ста
раться полностью охватить модульными тестами окружающий модель код, который
можно легко протестировать с их помощью, а для самой модели искать альтерна
тивные решения. Весь код загрузки данных, предварительной обработки, постобра
ботки выходных сигналов модели и прочие вспомогательные методы обычно легко
поддаются обычному тестированию. Кроме того, небольшого количества нестрогих
тестов самой модели — формы входных и выходных сигналов, например, в совокуп
ности со стилем тестирования «проверить, что модель не генерирует исключение
после первого же шага обучения» — вполне достаточно в качестве минимальной
тестовой обвязки модели, чтобы чувствовать себя в безопасности при рефакторинге.
(Как вы, наверное, заметили при экспериментах с примерами кода из предыдущих
глав, для тестирования в tfjsexamples мы использовали фреймворк тестирования
Jasmine, но вы можете использовать любой фреймворк модульного тестирования,
какой только нравится вам и вашей команде).
480
Do'stlaringiz bilan baham: |