Итак, в ходе моего эксперемента, как это часто бывает, я отошел немного в сторону и погрузился в рассмотрение работы TFX pipeline. Что на самом деле довольно не плохо, так как теперь понимаю как он работает.
Однако TFX, как и большинство опен сорс софта, имеет свои проблемы:
- Как я писал в предыдущем посте, компоненты работают в основном только с тренировочным и оценочным (train, eval) наборами данных
- Версия TFX 0.15 работает только с estimator API — однако говорят что в версии 0.21 ввели поддержку keras моделей без конвертирования ее в estimator, к сожалению не удалось это опробовать, так как в этой версии они сломали interactive context. Конечно, можно было бы и без него, просто все компоненты загнать в пайплайн, но хотелось, что бы и в ноутбуке все работало.
- При использовании keras моделей, так и не разобрался как заставить работать TFMA в полную силу, а штука выглядит забавной. Если кто то в курсе, буду рад совету %).
В общем и целом можно смело использовать все эти технологии, но лучше без интерактивных компонентов. Загоняем все в apache beam и строим модельки, проверяем, лучшие используем :). Думаю простейший метод это простой конвейер с функцией трансформации данных и самой моделью. Остальное можно и проигнорировать для домашнего пользования.
Собственно вот видюшка, про все это
Буду рад, если найдете время на посмотреть.
Собственно, есть еще такой религиозный вопрос касательно данных. Как и где их обрабатывать.
- Скажем если есть у меня набор исторических даннах, я могу сформировать все входящие фичи еще на этапе подготовки данных, потом в блоке трансформации нормализовать их и изменить формат пригодный для наших моделей, далее обучаем модель.
- На этапе подготовки мы берем просто сырые данные и шлем их в наш конвейер, там генерируем фичи, может быть что то еще подтягиваем с базы данных и получается у нас совершенно новый набор входных фич.
Если в первом случае у нас набор/количество фич на входе будет равен набору на выходе из функции обработки, то во втором они могут быть совершенно разные. Что, кстати, и происходит в примере на видео, и отсюда вытекают проблемы с использованием кераса и модуля для анализа моделей.
И опять же, не ясно как лучше делать в реальной торговли, готовить фичи до того как их в модель загонять, или же подавать только последние поступившие данные, а там уже как в пункте 2 тянуть все со второстепенных источников.
Если кто пользует машинное обучение и нейронные сети, как решаете эту проблему?
зы. ссылка на код из видео
https://github.com/CloseToAlgoTrading/CodeFromVideo/tree/master/episode_10
Я на PyTorch пишу, поэтому ваши проблемы возможно не до конца понимаю, но в общем это зависит от ситуации.
Если фичи тяжело считать на лету, то возможно их целесообразно предвычислять. У меня в принципе была такая ситуация, что расчет фичей на лету занимал 95% времени, собственно операции с графом 5%. С каждой эпохой обучения выгода от предвычисления растет.
Обратная сторона — фичи могут занимать в разы больше, чем исходные данные. Допустим у вас ряд котировок 1 млн значений, а вы на вход подаете в качестве фич слайс из 252 подряд идущих значений. Фичи у вас будут занимать 252 раза больше места, чем исходные данные для их построения. Наверное тут целесообразно вычислять на лету.
В общем надо профайлить — я в итоге решил считать на лету, но переписал все для максимального ускорения. Раньше расчет фичей делал в Pandas и Numpy, а переписал все прямо в PyTorch с отключенным расчетом градиентов. В результате расчет фич стал в ~100 раз быстрее идти.