Всё верно. Чтобы применить эту стратегию на практике нужно будет разобраться ещё со многими вещами и их учитывать. Однако базовый принцип сохраняется. И, как мне кажется, он достаточно интересен с алгоритмической точки зрения.
Здесь важно понимать, что применяя метод наименьших квадратов мы предполагаем что шум имеет нормальное распределение. Если это не так, то нужно использовать другой подход.
Это очень философский вопрос, что значит обосновать. К примеру, дерево решений выдает правило вроде «если возраст больше 25.32 лет и есть работа с зарплатой больше 29,432 рублей то выдать кредит». Нейронная сеть же выдает правило вроде «если значение логистической функции от суммы возраста умноженного на 1.45 и зарплаты умноженной на 0.67 больше 0.5 то выдать кредит». И тут очень сложно обозначить грань между обосновынным условием и необоснованным.
С трейдингом все, кроме высоких комиссий, ясно. Но ведь трейдинг — это, наверное, не совсем то, что нужно обычным клиентам для инвестиций, разве нет?
Всегда думал, что было бы замечательно иметь приложение для инвестиций, которое бы не кричало каждым скрином «покупай/продовай скорее». Но, к сожалению, все приложения на рынке умеют показывать тикающие биржевые данные, но ни одно, к примеру, квартальные/годовые отчеты компаний в понятном виде.
Про многоколоночное представление для tf.data – это не совсем так. По крайней мере на уровне API. Там может быть абсолютно любая схема. Например, как у меня в параграфе про структурированные объекты.
Если интересны внутренности, то происходит все примерно следующим образом. Ядро TensorFlow, которые на C++, возвращает просто список объектов как std::vector (код тут). Обертка, которая на Python, специфицирует как этот список интерпретировать и как его превратить в иерархический объект (код тут). В итоге, в Python API мы работаем именно со структурированными иерархическими объектами, а не с колоночным представлением.
Что касается структурированных объектов, то tf.data с ними справляется очень неплохо, позволяет работать со сложными объектами и применять практически произвольную трансформацию. А еще читать из разных источников, делать concatenate, reduce, flat_map и так далее. А в чем риск писать трансформацию на питоне?
Запросы с трансформацией на стороне Ignite доступны только из Java API. Других способов, на сколько я знаю, в ближайшее время не предвидится.
По поводу сети, если обучение делается на одной машине, то кроме разницы +-5% мы ничего не получим. Если же мы думаем о распределенном DL, когда на каждом узле вычисляются градиенты только для локальных данных, разница уже заключается не в +-5%, а в теоретически неограниченной линейной масштабируемости. То есть, конечно, ограниченной передачей градиентов, но не данных, а значит теоретическая верхняя планка производительности намного выше. Мы как раз над этим сейчас работаем. Впрочем, с практической точки зрения, я бы не переходил к распределенному обучению, если ситуация позволяет делать его локально.
Сама по себе система интересная, вопрос лишь в применении. Если искать позитивные моменты, то эту же систему можно использовать для оценки и коррекции действий учителя. Дети отвлекаются — материал подается сухо, нужно его переработать. Дети заинтересованы — отлично. Такой же подход можно использовать для разделения по классам («кластеризации», если пожелаете), ведь одни ученики лучше реагируют на один тип подачи материала, а другие — на другой.
Всегда думал, что было бы замечательно иметь приложение для инвестиций, которое бы не кричало каждым скрином «покупай/продовай скорее». Но, к сожалению, все приложения на рынке умеют показывать тикающие биржевые данные, но ни одно, к примеру, квартальные/годовые отчеты компаний в понятном виде.
tf.data– это не совсем так. По крайней мере на уровне API. Там может быть абсолютно любая схема. Например, как у меня в параграфе про структурированные объекты.Если интересны внутренности, то происходит все примерно следующим образом. Ядро TensorFlow, которые на C++, возвращает просто список объектов как
std::vector(код тут). Обертка, которая на Python, специфицирует как этот список интерпретировать и как его превратить в иерархический объект (код тут). В итоге, в Python API мы работаем именно со структурированными иерархическими объектами, а не с колоночным представлением.tf.dataс ними справляется очень неплохо, позволяет работать со сложными объектами и применять практически произвольную трансформацию. А еще читать из разных источников, делатьconcatenate,reduce,flat_mapи так далее. А в чем риск писать трансформацию на питоне?Запросы с трансформацией на стороне Ignite доступны только из Java API. Других способов, на сколько я знаю, в ближайшее время не предвидится.
По поводу сети, если обучение делается на одной машине, то кроме разницы +-5% мы ничего не получим. Если же мы думаем о распределенном DL, когда на каждом узле вычисляются градиенты только для локальных данных, разница уже заключается не в +-5%, а в теоретически неограниченной линейной масштабируемости. То есть, конечно, ограниченной передачей градиентов, но не данных, а значит теоретическая верхняя планка производительности намного выше. Мы как раз над этим сейчас работаем. Впрочем, с практической точки зрения, я бы не переходил к распределенному обучению, если ситуация позволяет делать его локально.