От исследования к производству: как избежать основных ошибок
Авторы: Юрий Рапопорт, Рафаэль Феттая
В отличие от обычных проектов по разработке программного обеспечения, продукты, основанные на ИИ / данных, являются довольно новыми для большинства компаний, и пока неясно, как лучше всего перейти от исследований к производству. В следующей статье мы представляем некоторые уроки, извлеченные из развертывания решений машинного обучения в нескольких основных продуктах Checkpoint.
# 1 Обсудите показатели оценки с руководством, прежде чем что-либо делать
Удивительно, но мы обычно ждем первых результатов, чтобы решить, как мы хотим себя оценивать. И в большинстве случаев ваш директор или команда QA выберут совершенно другой способ оценки вашей работы. «Они не понимают машинного обучения!», - скажете вы, но они знают ваших клиентов и являются экспертами в предметной области ...
Чтобы стать специалистом по анализу данных, особенно в компании, не занимающейся машинным обучением, необходимо четко объяснять, что вы делаете, и объяснять, почему это работает. Это не означает передачу всех технических деталей в вашу иерархию, а описание того, как вы улучшаете текущие процессы и как это измерять. Это также включает понимание того, как работает компания и какие цели она ставит.
В разных отраслях используются разные KPI: рекламные технологии люди любят показатель CTR, в финансах это будет рентабельность инвестиций или в кибербезопасности ложноположительный / отрицательный рейтинг.
Только после того, как вы придете к соглашению по метрике, вы можете начать свой проект. Кроме того, вы сможете откалибровать свою модель, чтобы оптимизировать ее и доказать своему боссу, что вы действительно что-то делаете.
# 2 Получите хороший набор данных (я знаю, что вы знаете)
Это может показаться очевидным, и это действительно так. Но из-за этого мы потеряли так много времени.
НИКОГДА не начинайте проект Data Science, если вы не можете создать достаточно большой, актуальный и непредвзятый набор данных.
Если у вас еще нет доступа к набору данных, убедитесь, что его создание не слишком сложно / дорого. Не думайте, что ваше руководство будет поражено вашими первоначальными результатами и вложит много средств, чтобы получить данные, которых вы заслуживаете. В большинстве случаев их выбрасывают.
Набор данных должен представлять фактические производственные данные, и вы можете проверить его, только если у вас есть значительный возобновляемый набор тестов, который поступает непосредственно из этих производственных данных.
Например, для решения проблемы классификации нам часто требуется получить данные с разными ярлыками из разных источников (например, фишинговые электронные письма из репозитория с открытым исходным кодом и безопасные сообщения от вашей компании). Это нормально, если вы можете проверить свою модель на наборе данных, который поступает из одного источника в производственной среде, иначе вы рискуете перенастроить свои источники.
# 3 Разумно разделите работу между членами команды
При работе в большой команде лучше позволить участникам быть независимыми. Однако вы также хотите, чтобы индивидуальные вклады работали в гармонии друг с другом. Для некоторых сценариев проектов машинного обучения относительно легко добиться этого, используя следующую схему:
отдельные специалисты по данным могут работать параллельно над «Обработчиком данных 1»,…, «Обработчиком данных N». Затем попробуйте разные модели на подмножестве комбинированного набора функций.
Например, предположим, что мы хотим построить модель, которая обнаруживает фишинговые письма. Каждое электронное письмо, а, следовательно, и работа, можно разделить, например, между содержанием (тема, текст) и вложениями. Пока выходные данные препроцессоров «содержимого» и «вложений» имеют согласованный формат, их можно легко объединить и создать из них одну большую матрицу.
# 4 Разделение обучения и прогнозирования
Это происходит так: во время фазы исследования обучение и предсказание происходят почти одновременно, часто в одной записной книжке (и если вы используете sci-kit, то тренер и предсказатель на самом деле являются одним и тем же объектом), поэтому вы не делаете этого. действительно разделите код, используемый для совершенно разных задач. Тем не менее, однажды наступает момент, когда вам нужно отправить модель прогнозирования, и вы понимаете, что она действительно связана с обучающим кодом, который имеет множество зависимостей от вещей, которые вам на самом деле не нужны.
Поэтому хорошей привычкой было бы отделить код прогнозирования / оценки от обучающего кода с самого начала. Вы можете использовать код прогнозирования из обучения, но не наоборот.
Более того, поскольку алгоритмы прогнозирования обычно очень просты, они могут быть реализованы на разных языках для разных сред.
# 5 Код предварительной обработки данных должен работать везде
Создание конвейеров данных, предварительная обработка данных и их очистка - наименее блестящие части нашей работы, но иногда на это тратится большая часть времени.
Код предварительной обработки обычно прост и не требует сложной экосистемы.
Было бы разумно приспособить часть предварительной обработки к среде, которая требует меньше ресурсов (например, C или Go вместо Python), особенно если вам нужно запустить модель на клиентских машинах.
В Check Point нам однажды пришлось построить модель ОС и архитектуры с ограниченными ресурсами. Модель взяла на вход содержимое exe-файла и предоставила оценку вредоносности. Мы обучили модель на Python с помощью sci-kit, но нам нужно было предсказать на C. Чтобы избежать написания кода дважды, мы просто создали библиотеку C, которая могла преобразовывать файл в матрица и еще одна, которая принимает предсказатель и возвращает предсказание из матрицы. Код обучения импортировал эти функции C в Python, а затем запустил обучение.
# 6 Создайте инфраструктуру отчетности, чтобы каждый всегда мог легко видеть результаты
Даже на начальном этапе создания модели лучше иметь автоматический процесс, который повторно оценивает ваши модели, и пусть результаты оценки будут видны не только создателям модели, но и некоторым справедливым специалистам. и непредвзятые, но в то же время мягкие рецензенты. Таким образом, с одной стороны, у нас не будет соблазна обмануть себя, но с другой стороны, мы не будем полностью уничтожены ненавистниками.
Не следует проводить проверку самостоятельно, поскольку вы не хотите быть одновременно судьей и стороной! Действительно, поступая таким образом, вы легко можете внести предвзятость в своих результатах (например, играя с пороговыми значениями) и может разочаровать вашу иерархию, когда вы продемонстрируете реальные производственные результаты.
Хорошее решение - отображать результаты на общем веб-сайте с соглашением о том, как автоматически генерируются прогнозы.
Dash может быть хорошим решением для людей, которые вообще не знают Интернета
# 7 Управление версиями в науке о данных
Управление версиями проектов в Data Science немного отличается от обычной разработки программного обеспечения. Действительно, новая версия вашей модели может быть фактической модификацией кода или изменением данных, на которых вы ее обучали.
Например, поскольку мир кибербезопасности постоянно меняется, в Check Point мы довольно часто переобучаем нашу модель, чтобы включить в нее более свежие данные. Каждое повторное обучение выводит новую модель, которая создает новую «вспомогательную версию», которая включает ссылку на данные, на которых она была обучена. И наоборот, мы часто хотим добавить новые функции, переписать некоторый код и т. Д. Такие изменения включают новое развертывание в производственной среде, и они могут привести к более серьезным проблемам и потребовать тестирования. Как вы можете догадаться, мы называем эти выпуски «основной версией», у которых есть собственная ветка git. Каждая модель идентифицируется как по основной, так и по дополнительной версии, таким образом мы можем легко настроить резервные правила в соответствии с типом только что выпущенного нами выпуска и обнаружить источник любой ошибки.
# 8 Обучение модели должно быть независимым от базы данных и хранилища
При работе с большим количеством данных вы не можете хранить всю свою базу данных в памяти, и ваш обучающий код должен иметь возможность извлекать информацию из внешних источников (файловой системы или базы данных).
В нашем первом проекте, которым мы были, мы просто вставили все запросы к базам данных на этапе векторизации. Но через несколько месяцев мы решили изменить тип базы данных, и нам потребовалось переписать много несвязанной части кода, чтобы это произошло. Затем нас попросили запустить наш код в разных средах, с разными базами данных или вообще без базы данных. Мы заблудились и добавили в код тонны «если», чтобы заставить его работать, это выглядело ужасно.
Мы решили это, добавив немного абстракции.
Сделайте абстракцию отдельного образца или партии. Это будет ваш вклад в обучение и предсказание. Экземпляры этих абстракций смогут работать в разных средах.
# 9 Восстановление данных и кэш
У нас было несколько неудачных случаев, когда мы создавали модель на основе данных, хранящихся в базе данных, затем обновляли базу данных и больше не могли воспроизвести модель.
Исходные данные должны храниться , чтобы всегда можно было воспроизвести обучение. Иначе было бы очень сложно отлаживать старые модели.
Для ускорения работы рекомендуется использовать кеширование для хранения промежуточных результатов предварительной обработки. Однако мы должны всегда иметь возможность восстанавливать кеш из исходных данных и никогда не полагаться только на кешированные результаты.
# 10 Проводя исследования, всегда считай, что можешь потерпеть неудачу
Во-первых, как можно быстрее добейтесь результатов. Имейте в виду, что то, что вы делаете, можно выбросить. Идите глупо, даже если это подразумевает, что ваш код выглядит плохо или не запускается все время (в конце концов, вы не просто разработчик программного обеспечения). Помните, что вы всегда начинаете с POC.
Еще один важный момент: имея краткосрочные цели, вы можете мечтать о большом, но все же иметь прагматичные планы. Вы всегда должны быть уверены, что делаете постоянный прогресс.
Один из лучших и самых известных способов убедиться, что вы можете продолжать, - это сравнить свои результаты со случайным алгоритмом прогнозирования.
В любом случае, если ничего не получается, вы можете написать об этом статью из 10 баллов.
Авторы - специалисты по анализу данных компании Check Point Software Technologies Ltd.
Автор: Юрий Рапопорт и Рафаэль Феттайя с помощью Ави Шуа, а также Луи Гутманн.
