Насчет data leak вы так и не поняли. По простому ,например если у вас интервал 1 минута, надо как минимум ставить gap 60минут, (все индивидуально), ибо значения тренировки могут быть инертны и залезть в будущее. Поищите обязательно это уже давно стандарт.
Интересно, а насколько лучше работают такие модели по сравнению с базовыми? Например, использование константы (среднее на обущающем множестве) в качестве прогноза для всего тестирующего множества. Или использование X[t] напрямую в качестве прогноза для X[t+N] (где N - горизонт прогноза). Ну или стандартный ARIMA.
Оценивали ли вы накладные расходы (не знаю, правильное ли это слово - хотел написать тут overhead) вышего фреймворка? Если у меня простая модель которая выдает решение за 1-2 миллисекунды, то сколько мне прибавит blocks в простейшем конвеере (провалидировать данные, применить модель)?
Секцию про вспомогательный глагол do можно разбавить примерами с does - очень популярная тема в разговорах (вопрос / ответ) : Make sense? / Makes sense, Sound good? / Sounds good.
А вот "I have went" звучит дико, вообще ни разу не слышал.
Я в свое время стал "переводить" на автомате чувствительность/специфичность в полноту (recall) для классов 1 и 0. Ну а полнота это уже достаточно простая метрика для понимания. А так да, в терминилогии можно легко потеряться.
Спасибо! Мы в одном из проектов похоже дигались в этом же направлении, и да, мы тоже написали наш Anomaly Injector (для временных рядов) который мы используем для валидации моделей.
А еще было бы интересно узнать, есть ли у вас проблема дрифта данных или самих предсказывающих моделей (concept drift), и если есть, то как это дело мониторите и какие алгоритмы используете. И в целом, были ли какие-нибудь интересные и неочевидные трудности, с которыми пришлось бороться при разработке и развёртывании этих сервисов?
Глобально, задача заключается в логировании артефактов и метаданных выполнения всех пайплайнов, каждый из которых состоит из множества шагов. Это может быть полезно с разных точек зрения:
Удобный совместный (связанный) трекинг артефактов (параметры, наборы данных, модели) и метаданных.
Многие пайплайны, особенности в HPC ("AI for science") представляют собой сложные пайплайны с множеством индивидульных шагов, иногда с обратными связями (например, active learning).
Логирование, отладка и поиск ошибок
Повторное выполнение пайплайна, возобновление выполнения с определённой стадии.
Поиск всех вариантов конкретного, необработанного, набора данных.
Поиск всех моделей, которые были построены на основе конкретного набора данных.
Поиск наборов данных, которые были использованы для построения конкретной модели.
Рекомендация конфигурации пайплайна и гипер-параметров для новых задач.
Такие инструменты уже существуют, например TFX Pipelines / KubeFlow с MLMD. Некоторая поддержка есть в закрытых платформах, типа Weights and Biases.
Я не знаю, есть ли в открытом доступе нативная поддержка всего этого для MLFlow, и насколько такая поддержка может быть полезной в целом. Я разговаривал с исследователями и командами, у которых кроме MLFlow / W&B больше ничего нет, и для них такая поддержка была бы полезна.
Вот здесь есть немного информации о различиях в метаданных ML экспериментов и метаданных пайплайнов.
Было бы интересно почитать про детали интеграции MLFlow и Apache Airflow. В частности, используете ли вы MLFlow для трекинга метаданных конвееров (пайплайнов) машинного обучения? Например, если мой конвеер состоит из нескольких этапов (загрузка данных, предобработка, тренировка и тестирование), и каждый этап представляет собой отдельный MLFlow run, то связываете ли вы эти этапы друг с другом через метаданные входов/выходов каким-нибудь образом? Мы ради экспермента написали слой поверх MLFlow для решения этой задачи, посути получив достаточно простую реализацию того, что доступно при использовании TFX Pipelines / KubeFlow с MLMD (ML Metadata от Google). Интересно узнать, если кто-либо еще думает в этом направлении.
Очень круто! По ходу чтения появилось пару вопрсоов:
90 GB/s в all-reduce тестах удалось достичь при запуске теста на всех 137 машинах (т.е. используя 137 * 8 = 1,096 карт)?
Если это не является коммерческой тайной, то какие бенчмарки вы запускали что-бы оценить 4 vs 8 сетевых карт на узел? В частности, оценивали ли вы, например, влияние конфигурации с 4ми картами на узел на тренировку таких моделей, как GPT-3 (Megatron-LM), в которой есть все 3 типа паралелизма (tensor/pipeline/data) и которой нужно 16 узлов с 8 GPU каждой для одной реплики?
Да, верно. Я думал про ядра W как 3D тензор размерности (4, 4, N) состоящий из нулей и единиц, где N — количество валидных цепочек в матрице 4x4. Тогда операция Conv2D(X, W) даст 3D тензор, в котором пространственные индексы максимального элемента укажут на под-матрицу (4,4) исходной матрицы, а третий индекс укажет на конкретное ядро, т.е. укажет какие 4 элемента надо выбрать.
Если бы речь шла про сумму, можно было бы все распараллелить и оптимизировать через операцию свертки (Conv2D в данном случае) с несколькими ядрами. С другой стороны, так как числа по определению > 0, то логарифм произведения есть сумма логарифмов. Так что можно посчитать поэлементно логарифм, а потом применить операцию свертки.
PS — идея абсолютно не протестирована ).
Порекомендуйте, пожалуйста, статью на эту тему.
Интересно, а насколько лучше работают такие модели по сравнению с базовыми? Например, использование константы (среднее на обущающем множестве) в качестве прогноза для всего тестирующего множества. Или использование X[t] напрямую в качестве прогноза для X[t+N] (где N - горизонт прогноза). Ну или стандартный ARIMA.
Мне кажется, тут речь скорее идет про количество образцов (samples == instances == examples).
Круто! Пара вопросов:
Как бы вы сравнили blocks с Faust и Streamz?
Оценивали ли вы накладные расходы (не знаю, правильное ли это слово - хотел написать тут overhead) вышего фреймворка? Если у меня простая модель которая выдает решение за 1-2 миллисекунды, то сколько мне прибавит blocks в простейшем конвеере (провалидировать данные, применить модель)?
Есть же классическое "How you doin'?" )
Секцию про вспомогательный глагол do можно разбавить примерами с does - очень популярная тема в разговорах (вопрос / ответ) : Make sense? / Makes sense, Sound good? / Sounds good.
А вот "I have went" звучит дико, вообще ни разу не слышал.
В первом фрагменте с кодом где-то опечатка - количество информативных и избыточных фич превышает общее количество фич.
Я в свое время стал "переводить" на автомате чувствительность/специфичность в полноту (recall) для классов 1 и 0. Ну а полнота это уже достаточно простая метрика для понимания. А так да, в терминилогии можно легко потеряться.
Спасибо! Мы в одном из проектов похоже дигались в этом же направлении, и да, мы тоже написали наш Anomaly Injector (для временных рядов) который мы используем для валидации моделей.
У них на сайте в разделе Features есть анимация того, что внутри.
А еще было бы интересно узнать, есть ли у вас проблема дрифта данных или самих предсказывающих моделей (concept drift), и если есть, то как это дело мониторите и какие алгоритмы используете. И в целом, были ли какие-нибудь интересные и неочевидные трудности, с которыми пришлось бороться при разработке и развёртывании этих сервисов?
Глобально, задача заключается в логировании артефактов и метаданных выполнения всех пайплайнов, каждый из которых состоит из множества шагов. Это может быть полезно с разных точек зрения:
Удобный совместный (связанный) трекинг артефактов (параметры, наборы данных, модели) и метаданных.
Многие пайплайны, особенности в HPC ("AI for science") представляют собой сложные пайплайны с множеством индивидульных шагов, иногда с обратными связями (например, active learning).
Логирование, отладка и поиск ошибок
Повторное выполнение пайплайна, возобновление выполнения с определённой стадии.
Поиск всех вариантов конкретного, необработанного, набора данных.
Поиск всех моделей, которые были построены на основе конкретного набора данных.
Поиск наборов данных, которые были использованы для построения конкретной модели.
Рекомендация конфигурации пайплайна и гипер-параметров для новых задач.
Такие инструменты уже существуют, например TFX Pipelines / KubeFlow с MLMD. Некоторая поддержка есть в закрытых платформах, типа Weights and Biases.
Я не знаю, есть ли в открытом доступе нативная поддержка всего этого для MLFlow, и насколько такая поддержка может быть полезной в целом. Я разговаривал с исследователями и командами, у которых кроме MLFlow / W&B больше ничего нет, и для них такая поддержка была бы полезна.
Вот здесь есть немного информации о различиях в метаданных ML экспериментов и метаданных пайплайнов.
Было бы интересно почитать про детали интеграции MLFlow и Apache Airflow. В частности, используете ли вы MLFlow для трекинга метаданных конвееров (пайплайнов) машинного обучения? Например, если мой конвеер состоит из нескольких этапов (загрузка данных, предобработка, тренировка и тестирование), и каждый этап представляет собой отдельный MLFlow run, то связываете ли вы эти этапы друг с другом через метаданные входов/выходов каким-нибудь образом? Мы ради экспермента написали слой поверх MLFlow для решения этой задачи, посути получив достаточно простую реализацию того, что доступно при использовании TFX Pipelines / KubeFlow с MLMD (ML Metadata от Google). Интересно узнать, если кто-либо еще думает в этом направлении.
Очень круто! По ходу чтения появилось пару вопрсоов:
90 GB/s в all-reduce тестах удалось достичь при запуске теста на всех 137 машинах (т.е. используя 137 * 8 = 1,096 карт)?
Если это не является коммерческой тайной, то какие бенчмарки вы запускали что-бы оценить 4 vs 8 сетевых карт на узел? В частности, оценивали ли вы, например, влияние конфигурации с 4ми картами на узел на тренировку таких моделей, как GPT-3 (Megatron-LM), в которой есть все 3 типа паралелизма (tensor/pipeline/data) и которой нужно 16 узлов с 8 GPU каждой для одной реплики?
"Say that again please" - еще один безумно распространенный разговорный вариант.
На мели сидит.
PS — идея абсолютно не протестирована ).