🥒7 причин не использовать Pickle для сохранения ML-моделей
Data Scientist часто пишет код в блокнотах типа Jupyter Notebook, Google Colab или специализированных IDE. Чтобы перенести этот код в производственную среду, его надо преобразовать в легковесный формат обмена, сжатый и сериализованный, который не зависит от языка разработки. Одним из таких форматов является Pickle – бинарный вариант Python-объекта для сериализации и десериализации его структуры, преобразующий иерархию объектов Python в поток байтов и наоборот. Формат Pickle довольно популярен за счет своей легковесности. Он не требует схемы данных и весьма распространен, но имеет ряд недостатков:
• Небезопасно. Можно распаковывать только те pickle-файлы, которым вы доверяете. Злоумышленник может создать вредоносные данные, которые будут выполнять произвольный код во время распаковки. Смягчить этот риск можно через подписи данных с помощью hmac, чтобы убедиться, что они не были подделаны. Ненадежность связана не с тем, что Pickle содержат код, а с тем, что они создают объекты, вызывая конструкторы, упомянутые в файле. Любой вызываемый объект может использоваться вместо имени класса для создания объектов. Вредоносный код будут использовать другие вызываемые объекты Python в качестве конструкторов.
• Рассогласование кода. Если код изменится за время между упаковкой ML-модели в Pickle-файл и моментом его использования, объекты могут не соответствовать коду. Они по-прежнему будут иметь структуру, созданную старым кодом, но пытаться работать с его новой версией. Например, если атрибут был добавлен после создания Pickle, объекты из Pickle-файла не будут иметь этого атрибута. А если в новой версии кода предполагается его обработка, возникнут проблемы.
• Неявная сериализация. С одной стороны, формат Pickle удобен тем, что он сериализует любую структуру Python-объекта. Но при этом нет возможности указать предпочтения по сериализации того или иного типа даны. Pickle сериализует все в объектах, даже данные, которые не нужно сериализовать. Но пропустить сериализацию того или иного атрибута в Pickle нет возможности. Если объект содержит атрибут, который нельзя упаковать, например, объект с открытым файлом, Pickle не пропустит его, настаивая на попытке его упаковать, а затем выдаст исключение.
• Отсутствие инициализации. Pickle хранит всю структуру объектов. Когда модуль Pickle воссоздает объекты, он не вызывает метод init, поскольку объект уже создан, считая инициализацию вызванной, когда объект был впервые создан в процессе создания Pickle-файла. Но метод init может выполнять некоторые важные действия, например открывать файловые объекты. В этом случае необработанные объекты будут находиться в состоянии, несовместимом с методом init. Или инициализация может регистрировать информацию о создаваемом объекте. Тогда невыбранные объекты не будут отображаться в общем логе.
• Нечитаемый. Pickle — это поток двоичных данных, т.е. инструкции для абстрактного механизма выполнения. Открыв Pickle как обычный файл, его содержимое нельзя прочитать. Чтобы узнать, что находится в нем, придется использовать модуль Pickle для загрузки. Это может затруднить отладку, поскольку сложно искать нужные данные в двоичных файлах.
• Привязка к Python. Будучи Python-библиотекой, Pickle специфичен для этого языка программирования. Хотя сам формат может использоваться для других языков программирования, найти пакеты, обеспечивающие такие возможности, довольно трудно. Кроме того, они будут ограничены межъязыковыми общими структурами объектов list/dict. Pickle без проблем сериализует объекты, содержащие вызываемые функции и классы. Но формат не хранит код, а только имя функции или класса. При распаковке данных имена функций используются для поиска существующего кода в запущенном процессе.
• Медленный. Наконец, по сравнению с другими методами сериализации, Pickle работает намного медленнее.
Поэтому MLOps-инженеру для переноса ML-моделей лучше рассмотреть другие универсальные форматы упаковки алгоритмов машинного обучения: JSON, marshal, cattrs и protocol buffers, ONNX, PMML или NNEF.