Tорговая система на базе глубокого обучения от начала до реальных торгов. Часть IV. TFX продолжение.

Итак, в ходе моего эксперемента, как это часто бывает, я отошел немного в сторону и погрузился в рассмотрение работы 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

tensorflow algotrading deep learning machine learning closetoalgotrading

CloseToAlgotrading

CloseToAlgoTrading

не определен

113

814

с 11 февраля 2016

10 Комментариев

Михаил
14 февраля 2020, 13:17
Я на PyTorch пишу, поэтому ваши проблемы возможно не до конца понимаю, но в общем это зависит от ситуации.

Если фичи тяжело считать на лету, то возможно их целесообразно предвычислять. У меня в принципе была такая ситуация, что расчет фичей на лету занимал 95% времени, собственно операции с графом 5%. С каждой эпохой обучения выгода от предвычисления растет.

Обратная сторона — фичи могут занимать в разы больше, чем исходные данные. Допустим у вас ряд котировок 1 млн значений, а вы на вход подаете в качестве фич слайс из 252 подряд идущих значений. Фичи у вас будут занимать 252 раза больше места, чем исходные данные для их построения. Наверное тут целесообразно вычислять на лету.

В общем надо профайлить — я в итоге решил считать на лету, но переписал все для максимального ускорения. Раньше расчет фичей делал в Pandas и Numpy, а переписал все прямо в PyTorch с отключенным расчетом градиентов. В результате расчет фич стал в ~100 раз быстрее идти.
+1
- CloseToAlgoTrading
  14 февраля 2020, 13:52
  Михаил, Да вот именно последних два абзаца меня скажем так волнуют и смущают. Если у меня 100000х252 фичи ) то мне просто нужен большой диск или база данных, но вот решил я поменять скажем 252 на 600 и все надо пересчитыватью.
  
  Конкретно в тфх меня смущает что в их эталонном пайплайне они создают метамодель описывающие входные сырые данный и делают некоторый статистический анализ именно сырыз данных, а потом вроде как предлагают их трансформировать, но! трансформировать то можно поразному.
  И вот дальше в этом же подходе, предлагается проанализировать модель, исходят из того, что ты будешь рассматривать сырые фичи. В общем :) тут я немного мне кажется не допонял идеи.
  
  А так то да, в идеале что торч что тенсорфлоу предлагают функциональность на лету все клепать, и это мне кажется правильный подход.
  
  А вы когда модель используете, данные сырые которые 252 подряд идущих, из файла, базы данных тащите или просто собираете их и как набралось нужное количество шлете в модель?
  я имею ввиду не обучение, а уже когда используете в продакшене :)
  0
  - Михаил
    14 февраля 2020, 14:15
    Denis,
    но вот решил я поменять скажем 252 на 600 и все надо пересчитывать
    Вряд ли вы будете менять это каждый день, особенно в продакшене. Решите поменять — посчитаете один раз ночью, а потом каждый день инкрементально будете досчитывать. На самом деле отдача есть, если вы тренируете больше одной эпохи, а это всегда так. Вопрос большая она или нет — зависит от данных и сложности фич.
    Конкретно в тфх меня смущает что в их эталонном пайплайне
    
    Я вам еще в прошлый раз писал, что вы по моему, чем-то не тем занимаетесь — у вас скорее исследовательская задача, которую можно и нужно делать без фреймворков, которые под продакшен придуманы. И как выясняется эта система еще и сырая, чего-то там не поддерживает. Рисеч все делают даже не в py файлах, а ноутбуках — так получите хотя бы в ноутбуке чего-то минимально работающее, а потом думайте, как его в продавшей раскатать.
    
    И как правильно вы поймете только после первого результат — как часто вам нужно будет переучивать модель? Может вы ее обучите один раз и будете месяцами использовать, а может нужно доучивать практически на лету? Сколько будет данных, будут ли они лезть в память? Насколько сложно считать фичи? Как вы будете исполнять — может вам для быстрой торговли нужно будет на C все переписать, а не REST север разворачивать на Python, как вы где-то писали.
    
    «я имею ввиду не обучение, а уже когда используете в продакшене :)»
    
    У меня стратегия инвестиционная, поэтому мне не нужен какой-то суровый продакшен. В моем случае это выглядит так:
    Раз в день в 19.45 на MOEX обновляются данные ISS. Я запускаю скрипт, он докачивает все обновления данных в MongoDB. Далее все необходимые данные берутся из базы (в моем случае они легко влезают в память и это не только котировки из ISS). С нуля учится модель, а фичи генерятся на лету иногда с lru_cache. Делается предсказание на следующий день по примерно 100 инструментам. К предсказаниям применяется, условно назовём, портфельная теория. Далее выдается рекомендация, какой инструмент в моем портфеле нужно продать, а какой купить, или рекомендация ничего не трогать. Все от начала скачки до рекомендации занимает около 5 минут.
    
    Где-то раз в месяц я запускаю процедуру байсовской оптимизации гиперпараметров модели — она занимает около суток.
    
    Торгую я ручками по этим рекомендациям, благо сделок немного и далеко не каждый день.
    +2
    - CloseToAlgoTrading
      14 февраля 2020, 14:44
      Михаил, спасибо за развернутый ответ.
      Я вам еще в прошлый раз писал, что вы по моему, чем-то не тем занимаетесь — у вас скорее исследовательская задача...
      Тут у меня есть еще просто интерес в технологиях покапаться.
      Все исследования по старинке в питоновском ноутбуке делаю.
      
      может вам для быстрой торговли нужно будет на C все переписать, а не REST север разворачивать на Python, как вы где-то писали.
      Ну тут проблем как раз таки с тенсорфлоу еще нет :), он отлично коннектится через gRPC.
      0
      - Михаил
        14 февраля 2020, 14:53
        Denis, можно покопаться в технологиях, которые более актуальны для решения задачи — делаете простой генератор признаков, простой луп для обучения и простую процедуру оценки качества ваших предсказаний. И исследуйте десятки архитектур, которые можно попытаться применить, пока результат не получите.
        
        А потом будет ясно этот скрипт, как у меня, REST сервер, gRPC или монолитное высокооптимизированное приложение на колокейшене, а модель вы будете например офлайн тренировать, а потом ночью грузить на сервер колокейшен, чтобы использовать на следующий день. А то и вообще ничего путного не получится, что тоже бывает.
        
        Мне вот например пришлось написать некий генератор описания параметров модели, используемых признаков и их параметров, а также процедуру сборки и обучения модели по этому описанию, чтобы подбор оптимальной модели производить, хотя когда я начинал, вряд ли я об этом думал. И вряд ли есть такое готовое решение.
        +1
        CloseToAlgoTrading
        14 февраля 2020, 15:14
        Михаил, Вы в целом абсолютно правы, ну может я только вот с этим утверждением в корне не согласен:
        И исследуйте десятки архитектур, которые можно попытаться применить, пока результат не получите.
        
        я думаю, что все же от данных надо отталкиваться, а потом уж модель, ну это другой вопрос уж.
        
        Мне вот например пришлось написать некий генератор описания параметров модели
        Так ведь все эти модные технологии, я про тфх, как раз таки и направленны на автоматизирование этих действий, а значит и экономии времени на исследования. Хочется в это верить :)
        0
        Михаил
        14 февраля 2020, 15:26
        Denis, я могу ошибаться, но основная его задача — развертывание систем в продавшен. Причем продавшен достаточно определенный, который интересен Google и прочим web-сервисам, — много запросов от многих пользователей, на которые нужно отвечать в пределах секунды — сотен милисекунд. То есть он заведомо не подходит для наших целей — у вас скорее всего будет один клиент. Причем, если это HFT — то скорости будет недостаточно, а если инвестиции, то будет избыточно.
        
        А по-поводу сетей и данных: вся история NN — это поиск все более совершенных архитектур для тех же данных. Картинки или текст давно существуют и ничего нового с ними не делают, но постепенно изобретают RezNet или BERT. У вас тоже вряд ли будут какие-то необычные данные. Скорее всего дальше котировок вы никуда не уйдете, а если уйдете, то это будет отдельное непростое приключение по поиску и сбору данных. Поэтому основной ваш инструмент — это правильно подобрать архитектуру.
        0
        CloseToAlgoTrading
        14 февраля 2020, 15:58
        Михаил, думаю вы не ошибаетесь, в основном конечно гугл его для больших систем придумал.
        
        Поэтому основной ваш инструмент — это правильно подобрать архитектуру.
        
        Боюсь что все в это и выплывет, хотя мне такой подход не нравится, это такой каггл подход, берем какие-то данные и начинаем искать архитектуру, а вдруг повезет. То же кстати с анализом фич происходит, сеть что то выдает хорошее значит и фичи хороши.
        Я люблю исходить все же от понимания данных. Хотя именно в этом эксперементе который пытаюсь реализовать, все идет в обратную сторону ).
        0
        Михаил
        14 февраля 2020, 20:06
        Denis, никто не мешает архитектуру придумывать с учетом особенности данных. Ряд равноправных значений — наверное нет смысла пробовать Dense слой, а лучше взять Conv или LSTM. На практике люди используют годовые скользящие средние, а в исследованиях аномалий рынка один из важных факторов годовой моментум, наверное нужно грузить в сеть историю за год, то есть порядка 252 значений, но на таких последовательностях LSTM уже не работает, поэтому видимо Conv. Учитывая, что дневные данные имеют периодичность в 5 рабочих дней, разумно попробовать свертки 5. Если учить, на данных многих инструментов, разумно добавить эмбединг инструмента, его отраслевой принадлежности и т.д.
        
        И в кагле реальные чемпионы не пробуют все подряд, они знают, что обычно заходит, как тюнить модели под конкретные задачи, хотя для не знающего это кажется беспорядочным перебором.
        0
bozon
15 февраля 2020, 07:54
Как же у Вас всё сложно с анализом данных. Из своего короткого опыта анализа данных я знаю, что всю сложность архитектуры базы расчётов можно упростить через набор стандартных терминальных индикаторов. При этом «правильных» моделей можно построить точно больше одной.
0