Недавняя разработка пакета сделала обработку данных действительно жизнеспособной.

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

Однако благодаря футуристическим и захватывающим успехам, достигнутым разработчиками Julia, предварительная обработка пошла дальше, чем я когда-либо думал изначально. В результате Джулия стала гораздо более жизнеспособным вариантом для машинного обучения в целом. Благодаря роскошным дополнениям к Genie и соответствующей документации развертывание API стало

торт прогулка.

Genie управляет всеми виртуальными средами за вас, и теперь эта документация выпущена и постоянно улучшается замечательным разработчиком Essenciary (Адриан Салчану), что делает Джулию более удобной для повседневного использования в качестве веб-фреймворка.

PyCall

Это может показаться неожиданным, но одной из самых серьезных проблем, с которыми в настоящее время сталкивается Джулия, является PyCall.jl. Это связано с тем, что в его нынешнем виде слишком много пакетов зависят от него и, в свою очередь, зависят от Python. Хотя я полностью понимаю, что экосистема Python намного больше, чем у Джулии, Джулия, в свою очередь, теряет всю полученную скорость, а с PyCall может работать даже медленнее, чем при использовании самого Python,

так зачем вообще использовать Юлию?

Поезд-Тест-Сплит

Train-Test-Splitting - важный инструмент, который полностью необходим для любого участка машинного обучения. Чтобы проверить алгоритм, вы должны сначала иметь поезд и набор тестов, а некоторые даже выбрать набор для проверки. Ссылаясь на эту ветку,



В дискурсе Джулии, я думаю, довольно очевидно, что разделение тестового поезда для фреймов данных в некоторой степени упускается из виду. MLDataUtils, вероятно, является наиболее часто используемым пакетом для Train-Test-Split, и поверьте мне на слово:

Конечно, могло быть лучше.

К счастью, вот уже несколько месяцев, как модуль Lathe стал лучше.

using Lathe.preprocess: TrainTestSplit
train, test = TrainTestSplit(df)

И мы даже можем настроить наш разделенный процент, например:

train, test = TrainTestSplit(df,0.5)

Это разделит данные для наших тестовых и обучающих наборов пополам.

Масштабирование функций

Что-то, что, на мой взгляд, слишком часто встречается в модулях Julia, - это формальность SkLearn. Я не думаю, что мы должны принимать или применять эту конформацию из совершенно отдельного языка, основанного на совершенно отдельной парадигме. Прекрасным примером этого являются скаляры функций внутри Julia. Большинство, если не все скаляры функций соответствуют стилю написания SkLearn, который определяет модули машинного обучения Python с 2010 года. Но причина того, почему скаляры SkLearn ведут себя таким образом, заключается в одной единственной причине, и это замечательные конвейеры SkLearn.

В Julia у нас нет классов, а методы, в свою очередь, не могут быть дочерними по отношению к объекту. Вместо этого у нас есть структуры, которые могут принимать метод для выполнения действия с данными, которые хранятся в структуре. Вдобавок, единственные конвейеры, которые может предложить Джулия, - это синтаксические конвейеры, которые хороши, но, безусловно, исключают точку соответствия SkLearn, учитывая, что они не используют одни и те же методы. Чтобы представить это в перспективе, это формула для стандартного скаляра (нормализатор Z-показателя):

С помощью такой простой формулы единственное, что вычисляется при подборе, - это выборочное среднее и стандартное отклонение. Со скоростью Джулии эти вычисления, конечно, выполняются за микросекунды, как и в Python. Ни в коем случае это не представляет собой сложного вычисления, выполняемого в одном кратком цикле for и двух дополнительных строках. К счастью, Lathe снова применяет простой метод, который принимает любой массив:

using Lathe.preprocess: StandardScalar
scaledX = StandardScalar(trainX)

Довольно просто, правда?

В дополнение к стандартному скаляру, Lathe также поставляется с множеством других скаляров, и в будущем также есть планы реализовать скаляр единичной длины. На данный момент листинг Lathe.preprocess с помощью метода? () Покажет нам все доступные скаляры:

  • Рескалар
  • Произвольное изменение масштаба
  • Средняя нормализация

Категориальные кодеры

Категориальные кодировщики - еще одна область экосистемы Julia, которой крайне не хватало. Доступен только один энкодер, обычно он используется через Flux и называется одним горячим энкодером. Чтобы дать вам представление о том, насколько бессмысленно чрезмерно усложнять один горячий кодировщик Flux, вы можете взглянуть на исходный код здесь:



Код в этом файле насчитывает 130 строк, что, на мой взгляд, совсем не обязательно. Чтобы использовать горячий кодировщик Lathe, мы просто вызываем метод OneHotEncode:

using Lathe.preprocess: OneHotEncode
encoded_df = OneHotEncode(df,:columnname)

А вот код, который это вычисляет, всего за 7 строк:

Трубопроводы

Конвейеры - очень важная функция для SkLearn и машинного обучения в целом. Джулии очень не хватает действительно хорошей библиотеки для использования конвейеров. Большинство конвейеров в Julia не принимают построенные модели и запрещают какие-либо легкие операции сериализации для чтения и записи. Однако в Lathe есть конвейеры, которые используют ту же функцию прогнозирования, что и остальные модели Lathe, и допускают повторяющийся набор шагов, а также модель для прогнозирования. Если вы хотите прочитать полное, хотя и устаревшее руководство по конвейерам Lathe, вы можете проверить его здесь:



Кроме того, для получения ценной документации вы можете просто использовать метод? () В Lathe.models.Pipeline.

Заключение

Я считаю, что многие модули Julia оставляют желать лучшего. Некоторые вообще не предлагают совместимости с фреймами данных, в то время как другие создают еще больше проблем, бессмысленно усложняя простые алгоритмы. Язык Julia чрезвычайно гибкий, и это может быть использовано не только в ноутбуках, но и в модулях. Я думаю, что экосистема Julia отталкивает многих новых людей, приходящих на язык именно по этой причине, и это меня расстраивает. По правде говоря, с точки зрения пакетов, прямо сейчас Python легко справился с этим лучше. Я думаю, что это можно легко изменить, и, глядя в будущее, я очень рад, где будет экосистема Julia, включая Lathe!