Настоящий единорог: данные для тестирования машинного обучения

Давайте будем честными здесь; вы были на той встрече, где все кивали головами в знак согласия с тем, что хороший, упорядоченный рабочий процесс разработки → постановка → производственный процесс будет своевременно обнаруживать проблемы, черт возьми, это даже звучит как функциональное программирование! Но затем неизбежно последующее совещание о том, как # $ & #! ( нулевой указатель мог остановить производство, когда та самая сборка прошла тесты.

По моему опыту, это почти всегда проблема с данными. Код был протестирован. Производственные сбои по-прежнему возникают, потому что, если вы не протестируете их на реальных производственных данных, вы все равно не проверили наиболее критический вариант использования. Код прошел интеграционные тесты с тестовыми данными так же, как он прошел модульные тесты с тестовыми данными (возможно, меньшего размера). По сути, в этом традиционном программном рабочем процессе отсутствует идея о том, что данные, проходящие через код, так же важны, как и сам код. Это не означает, что мы должны просто версировать все данные. Помимо того, что это непрактично для типичных корпоративных рабочих процессов, он упускает из виду тот момент, что успех здесь означает, что он работает в производственной среде. Если бы вам пришлось выбирать между кодом, который работает только в продакшене, или только в постановке, что бы вы выбрали? Когда мы говорим о машинном обучении, особенно на редких данных, это может быть реальным выбором. Так как же решить эту проблему?

По-разному…

Это снова мы. В мире нет уверенности; мы плывем по течению! Это правда, что это было проще, чем когда вы редактировали свою работу, кладя стопку перфокарт на полку, но не бойтесь, в этом вся суть. Машинное обучение интересно именно потому, что это больше, чем статическое детерминированное преобразование. Исследователи в области образования (немашинное обучение) десятилетиями пытались протестировать отдельный компонент процесса обучения, потому что группы маленьких людей (школьные классы) представляют собой фантастически изменчивые и сложные вычислительные единицы. Теперь настала очередь мира высоких технологий.

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

Теперь представьте, что вместо этого вы пытаетесь оценить, какой алгоритм 1 или 2 лучше подходит для выработки рекомендаций по продукту. Те же вызовы, другая терминология. Вместо классных комнат у вас есть среда разработки. Алго 1 сейчас находится в производстве и поэтому работает на более мощном оборудовании. Алго 2 быстрее, чем Алго 1 при тестировании, но это только потому, что Алго 1 больше нагружает сеть, а в промежуточной среде нет того красивого коммутатора 10 Гб, который вы только что установили в производственной среде. Те же вопросы относятся к данным. Алгоритм 1 масштабируется линейно, а алгоритм 2 - O (n2), поэтому при заданных тренировочных усилиях алгоритм 2 выигрывает по тестовым данным, но потерпит неудачу при переходе в высшую лигу.

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

Подключение вашего теста ML

Тестируемый ML == Продуктивный ML

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

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

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

Что такое постановка при попытке протестировать несколько вещей одновременно?

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