Я знаю только один способ «конкретно» — это на примере. Возможно, у меня дойдут руки и я таки опубликую заметку на медиуме c примерами. Так что с «конкретно» вынужден разочаровать.
Тем не менее, попробую ответить не_конкретно. Потому что в каждом конкретном случае свои нюансы, у нас пока недостаточно примеров в этой области, чтобы систематизировать нюансы и говорить о наличии каких-то системных правил и подходов; кустарный метод, если хотите.
Итак, в ооочень грубом приближении подход такой:
Цикл 0.
Выбираем детализацию симулятора моделируемой среды. Представьте себе, что у вас есть эмпирический «закон», для простоты у вас среда элементарная и «закон» один (например, уравнения Навье-Стокса в общем виде для течения вязкой жидкости, или уравнения Жаботинского-Корзухина для описания колебательных химических реакций), в каждом законе есть возможность сделать какие-то допущения и упростить вид «закона», отбросив какие-то слагаемые уравнений. Итак, итерируемся по разным видам «законов».
Цикл 1 внутри Цикла 0. Шаг 1. Берем трейн-сет Т1, на нем подбираем (тут можно целый пост о том, как именно) такие коэффициенты при компонентах «закона», при которых трейн Т1 описывается с минимальной ошибкой Шаг 2. Генерируем синтетическую обучающую выборку ТS. Строим сетку в области НТР для управляемых параметров и в области наблюдаемых значений неуправляемых переменных. Далее или равномерно, или учитывая частоту встречаемости данных сочетаний параметров на исторических данных, или по какому-либо другом распределению частоты в этой сетке — семплируем нужное количество синтетических наблюдений при помощи полученного симулятора Шаг 3. Экспериментируем с моделями — обучаем модели на выборке (или подвыборке) TS и реальных данных T2, генерируем фичи, подбираем гиперпараметры (доля синтетических данных — можно воспринимать как гиперпараметр или задавать жестко как степень «физичности» модели). По факту тут еще целое семейство циклов подбора параметров, но вроде досаточно понятно как мы получим в итоге некоторый набор моделей с лучшими значениями метрик на полусинтетическом трейн-сете. В случае нейронок есть, кстати, смысл обучать вначале на TS, а потом на T2 (только learning_rate нужно подзадрать, если использовался decay) Шаг 4. Строим скор-борд моделей на данных выборки Т3.
Далее возвращаемся в Цикл 0 и в зависимости от выбранного подхода (от простого к сложному или наоборот) или убираем, или добавляем допущения. Последотвательность отработки допущений и наборы законов строятся человеком, разбирающимся в предметной области.
Как-то так получается модель.
При этом я оставил за кадром вопрос с выбором временного окна агрегации для описания процесса, тоже отдельный вопрос (если он не задан явно из каких-то других соображений).
Прежде всего, если вы хотите продолжить разговор, пожалуйста, снизьте градус ваших изречений.
вы так и не ответили — train это данные технологов завода? Это то, что регистрируют их датчики, журналы и т.д. И оставьте физику в покое, отвечайте на конкретный вопрос
Разумеется. Конечно же, это данные того производства, для которого реализуется система. Я лишь дополнительно сакцентировал внимание на том, что есть и другие источники данных, коим является, например, приближенный симулятор процесса.
Если предложенный режим не описан в технологии — это и есть нарушение. Технология выплавки это вам не опенсорс, там нельзя просто так внести изменения.
Я же уже ответил — выхода за пределы установленных технологических режимов, установленных техрегламентами, не осуществляется. Система не может выдавать такие рекомендации в принципе.
Если требуемый режим указан в технологии и рабочий у станка им не пользуется — причем тут AI, ИИ, машинное обучение и прочие умные слова?
Потому что вы, вероятно, путаете «нормы технологического регламента (НТР)» и «технологический режим (ТР)». НТР — это диапазон возможных технологических режимов работы, установленных технологически регламентом для данной установки. ТР — конкретный режим, совокупность управляемых и наблюдаемых параметров, характеризующих работы установки. Конечно же, установка работает в каком-то конкретном ТР (в пределах НТР). Рекомендации системы заключаются в переходах на другие ТР, которые также находятся в пределах НТР. Я не встречал такого, чтобы НТР состоял только из одного ТР.
И по O&G — есть утвержденная технологическая схема и у нее есть авторы и она утверждена в ГКЗ, Росприроднадзоре и Ростехнадзоре и как вы вносите в нее изменения?
ТОлкаете нефтяников на преступление или в ваших рекомендациях нет ничего существенного и их не нужно вносить в техсхему и защищать?
Уже ответил — рекомендации работают строго в пределах регламента. Бывает, конечно же, и такое, что рекомендации упираются в предельные значения НТР в течение продолжительного времени (это пример не из O&G), в этом случае у самого владельца процесса могут возникнуть мысли или о внесении изменений в регламент, или о пересмотре целевой функции, которая оптимизируются (не учли какие-то долгосрочные эффекты или они имеют малый вес). В любом случае, это повод задуматься.
К сожалению, крайне сложно собрать репрезентативную выборку, чтобы иметь численные сравнения. Самому бы хотелось такую иметь. Так что надо сказать честно — пока все рассуждения на уровне заявляемых вендорами и нами эффектов и сопоставления со стоимостью таких внедрений.
И да, как я уже сказал, скорее всего разные подходы должны слиться в один, но пока каких-то конкретных успехов тут нет ни у одной из сторон. Пока есть намерения и декларации :)
Если взять идеально понимающего в процессах человека и посадить его перед монитором и заставить наблюдать и управлять процессом все время — конечно же, никакой ML дополнительно не нужен.
Проблем несколько — а) непрерывный контроль понимающим человеком — утопия, даже раз в полчаса подходить и смотреть/корректиррвать не у всех получается в силу совершенно разных причин, б) понимающий человек крайне быстро, со скоростью пропорциональной уровню понимания, идет вверх по должностям и перестает заниматься оперативным управлением установки, в) регламенты большинства предприятий устроены так, что операторы, которые действительно сидят и смортят на показания датчиков, отвечают за работу вверенной им установки (т.е. по оператору (точнее, обычно нескольким) на установку) только в пределах ее работы в заданных технологических режимах. Оптимальность текущего режима, не говоря уже о всем процессе, их не волнует, если говорить грубо.
Что касается логики работы самого процесса или установки — да, порой она бывает достаточно простая. Но почти всегда даже в самом простом процессе вылезает огромное количество нюансов, если вы хотите не просто смоделировать его работу, а управлять им, по возможности, оптимально. Там вылезают вопросы стоимости сырья (если используется разное), вопросы снижения ресурса оборудования из-за работы вблизи технологических режимов и т.п. Тут фокус сложности смещается с модели самого процесса (который действительно бывает простым) на процесс принятия решений/управления.
Неправильно. Нет цели получить новые знания как таковой. Есть цель построить две модели (в концепции RL они совмещены):
1. Модель процесса, которая а) учитывает известную физику процесса, б) достаточно точно воспроизводит процесс на доступных данных
2. Модель принятия решений с учетом того где мы находимся сейчас и какие возможности нам сейчас доступны, какой ожидаемый reward мы получим от каждого возможного действия.
Предложение нарушить технологию ...
Я изложил ровно обратное — не нарушать технологию. Для этого в т.ч. закладываются границы технологических режимов, за пределы которых рекомендации выходить не должны. Там есть нюансы, конечно же, с тем что если работать долго вблизи технологического предела, то это неизбежно приведет к более ранней поломке. Но обычно это также учитывается, правда чуть более тупо — бизнес-правилами (куда ж без них) в целевой функции модели принятия решений.
И по O&G тоже сомнения — там всегда можно локально снизить давление в НКТ и получить прибавку дебита, но после обязательно спад или ремонт.
Разумеется, что это учтено на уровне физической модели, плюс можно было бы дополнительно перестраховаться, выкрутив long- и short-term reward'ы (но мы пока обошлись без этого).
Больной для меня вопрос, отвечу подробно :)
В общем и целом, с точки зрения назначения — у APC и наших разработок оно одно и тоже — управлять (по возможности оптимально) процессом производства.
Различия такие:
Сигналы управления наших систем носят рекомендательный характер, и, даже если и попадают назад в АСУТП, то не идут на исполнительные контроллеры. В отличие от APC, которые именно там и «живут» и управляют процессом непрерывно — что дает, конечно же, больший эффект. Но почти всегда мы внедряемся там, где степень автоматизации небольшая.
APC (обычно) вешаются на несколько критичных установок, в то время как наши системы анализируют процесс целиком для выдачи оптимальных режимов, используя в т.ч. данные по стоимости сырья, что далеко не всегда могут APC.
APC обычно должно быть почти всегда или того же производителя что и АСУТП, или как минимум лицензировано им. Кроме того, оно должно быть лицензировано производителем установки. Нам не требуется ни того, ни другого.
В APC обычно вшит закон управления установкой, относительно неизменный со временем (в плане адаптации под деградацию оборудования и учет ремонтов). Наш подход другой, описан в статье. Хотя про APC не так все однозначно — тут конечно же надо смотреть уже на конкретных производителей типа Honeywell, Yokogawa и т.д., они же тоже не стоят на месте
Обычно внедрение APC в силу перечисленных фактов, особенно для предприятий с низким уровнем автоматизации, плюс стоиомость контроллеров — оказывается сильно дороже. Повторюсь, обычно. Нужно считать в каждом конкретном случае.
А вообще, я считаю, что в один прекрасный момент оба подхода должны соединиться в один -наши или аналогичные решения должны перепрыгнуть на контроллер. Или остаться жить на серверах, а контроллеры стать простыми исполнительными механизмами. Но до тех пор, пока будет сильно разниться степень автоматизации промышленности, будут жить оба подхода.
Автор просто осветил только ETL-возможности RapidMiner, которые, так сказать, скорее на втором плане. На самом деле инструмент для Data Mining / Machine Learning больше. Вот, например, посмотрите: docs.rapidminer.com/studio/getting-started/3-creating-model.html
Хотя RapidMiner Server и позволяет строить отчеты, но BI полноценный он заменить не может.
Недавно поймал себя на мысли, что в зарубежных data science блогах люди все меньше используют базз-ворд BigData. Даже там, где бумага его бы стерпела (с).
Потом увидел, что даже попсовый Gartner в своем Hype Cycle 2015 года убрал «BigData» (кстати, теперь там появился «Machine Learning»).
Похоже ажиотаж наконец-то начинает стихать.
Про техническую часть — все понятно и очень интересно, спасибо.
А какие бизнес-задачи решаете или решали, не могли бы рассказать коротенько, если не коммерческая тайна, конечно?
Как приходите к технической постановке задачи на исследование/разработку? Бизнес что-то спускает или сами что-то генерите? Формируются какие-то бизнес-требования и критерия качества? Как результаты ваших разработок и исследований до конкретных действий доходят?
Был бы признателен, если поделитесь своими соображениями и опытом на это счет.
А смысл платить за него и привязываться к проприетарному инструменту, если за интерпретатор python или за gcc никто денег вообще не просит?
Вы выводите вопрос в плоскость «opensource vs proprietary». Почему вообще эти глупые люди вокруг платят за софт, а не используют опенсорс? Почему у того же SAS 70 тысяч клиентов, они что дураки все, можно же на R/Python/etc все самому написать? Почему же люди покупают Cloudera и HortonWorks, а не используют Apache Hadoop?
Скорость разработки, удобство использования пользователями, управление правами доступа из коробки, оптимизации производительности, различные бесшовные интеграции из коробки, простота поддержки, разработка силами не ученых и математиков. Можете продолжить список.
Отдельное удовольствие – управлять разработкой команды из ученых и математиков. Я знаю несколько историй с печальным концом, начинавшихся со слов «класс, сейчас мы соберем ВМКшников и ШАДовцев, дадим им данные и будет у нас счастье».
Плох тот бизнес-аналитик, который не является математиком, а для математика не должно быть проблем с написанием кода)
По пальцам одной руки могу пересчитать бизнес-аналитиков, с которыми мне приходилось работать, и которые при этом хорошо владеют «математикой» в своей индустрии. При этом, поверьте, большинство бизнес-аналитиков отлично разбираются в предметной области и знают, что им и для чего нужно.
А хороший математик-программист – в большинстве случаев никудышный бизнес-аналитик.
Поэтому эти роли все нормальные организации и руководители, как правило, разносят если не в разные отделы, то на разных людей точно.
Пользовался. Периодически скачиваю, смотрю как развивается. До такого же детального сравнения я, наверное, не доберусь. Предлагаю скачать и то, и другое и сделать выводы самому.
Лично мое впечатление – я не смог все, что мне было тогда нужно (года полтора назад дело было) реализовать на KNIME. Плюс приходилось костыли городить из базовых блоков и loop'ов на функционал, который, как мне кажется, должен был бы быть в продукте. Я конкретику привести не вспомню сейчас, могу поискать, может где-то стрим сохраненный остался.
Ну и RM приятнее гораздо в работе (имхо, естественно).
Внесу немного ясности:
1. Вы можете взять исходники предыдущей версии и собрать сами RapidMiner без ограничений, но старый (версия 5.3).
2. Вы можете взять бесплатно Starter (уже собранный) текущей версии (6.3) – 1 Гб и без подключения к БД.
3. Вы можете попробовать триал текущей версии 14 дней – там нет этих ограничений.
4. И вы можете купить пункт (3) уже в долгое пользование.
Кого давит 1 Гб на процесс — собирайте код (или зарегистрируйтесь на сайте, потом можно скачать бинарники). Для большинства же малого бизнеса достаточно стартера, поскольку там функционал аналитики тот же. Если расчёт у вас ещё и разовый, вроде анализов результатов за год, то можно настроить процесс в Starter и взять триал, чтобы перемолотить данные. А потом решить, стоит покупать полную версию или нет.
Все верно, по заверениям разработчиков с выходом следующей мажорной версии предыдущая становится открытой.
Ограничения бесплатной 6-ой версии на текущую опенсорсную (5.3) не распространяются.
Однако, вы можете заметить, что 6-ая версия по сравнению с 5-ой сильно прибавила в функциональности, т.е. далеко не все вы сможете найти в опенсорсной версии.
Чисто для понимания – у ближайших конкурентов (кроме KNIME, о чем комментарий ниже) вообще нет бесплатных версий в каком-либо виде (SAS University Edition – не в счет, он для студентов), только триалы.
А описанная вами «любительская» задача далека от медианы аналитических задач даже среднего бизнеса. Нет, SNA и deep learning это круто, конечно, но далеко от «everyday data science» большинства аналитиков и разработчиков.
Про широту возможностей — нельзя не согласиться. Но тут другой момент уже — Assembler, конечно, круче по возможностям чем C, но с последним работать многим приятнее и понятнее…
Про удобство программирования на R и Python над визуальным интерфейсом — достаточно спорный тезис.
Да, и про кроссплатформенность я забыл упомянуть — RM работает на Windows, Linux и Mac. Причем все компоненты, и Studio, и Server.
Тем не менее, попробую ответить не_конкретно. Потому что в каждом конкретном случае свои нюансы, у нас пока недостаточно примеров в этой области, чтобы систематизировать нюансы и говорить о наличии каких-то системных правил и подходов; кустарный метод, если хотите.
Итак, в ооочень грубом приближении подход такой:
Цикл 0.
Выбираем детализацию симулятора моделируемой среды. Представьте себе, что у вас есть эмпирический «закон», для простоты у вас среда элементарная и «закон» один (например, уравнения Навье-Стокса в общем виде для течения вязкой жидкости, или уравнения Жаботинского-Корзухина для описания колебательных химических реакций), в каждом законе есть возможность сделать какие-то допущения и упростить вид «закона», отбросив какие-то слагаемые уравнений. Итак, итерируемся по разным видам «законов».
Цикл 1 внутри Цикла 0.
Шаг 1. Берем трейн-сет Т1, на нем подбираем (тут можно целый пост о том, как именно) такие коэффициенты при компонентах «закона», при которых трейн Т1 описывается с минимальной ошибкой
Шаг 2. Генерируем синтетическую обучающую выборку ТS. Строим сетку в области НТР для управляемых параметров и в области наблюдаемых значений неуправляемых переменных. Далее или равномерно, или учитывая частоту встречаемости данных сочетаний параметров на исторических данных, или по какому-либо другом распределению частоты в этой сетке — семплируем нужное количество синтетических наблюдений при помощи полученного симулятора
Шаг 3. Экспериментируем с моделями — обучаем модели на выборке (или подвыборке) TS и реальных данных T2, генерируем фичи, подбираем гиперпараметры (доля синтетических данных — можно воспринимать как гиперпараметр или задавать жестко как степень «физичности» модели). По факту тут еще целое семейство циклов подбора параметров, но вроде досаточно понятно как мы получим в итоге некоторый набор моделей с лучшими значениями метрик на полусинтетическом трейн-сете. В случае нейронок есть, кстати, смысл обучать вначале на TS, а потом на T2 (только learning_rate нужно подзадрать, если использовался decay)
Шаг 4. Строим скор-борд моделей на данных выборки Т3.
Далее возвращаемся в Цикл 0 и в зависимости от выбранного подхода (от простого к сложному или наоборот) или убираем, или добавляем допущения. Последотвательность отработки допущений и наборы законов строятся человеком, разбирающимся в предметной области.
Как-то так получается модель.
При этом я оставил за кадром вопрос с выбором временного окна агрегации для описания процесса, тоже отдельный вопрос (если он не задан явно из каких-то других соображений).
Как-то так :)
Разумеется. Конечно же, это данные того производства, для которого реализуется система. Я лишь дополнительно сакцентировал внимание на том, что есть и другие источники данных, коим является, например, приближенный симулятор процесса.
Я же уже ответил — выхода за пределы установленных технологических режимов, установленных техрегламентами, не осуществляется. Система не может выдавать такие рекомендации в принципе.
Потому что вы, вероятно, путаете «нормы технологического регламента (НТР)» и «технологический режим (ТР)». НТР — это диапазон возможных технологических режимов работы, установленных технологически регламентом для данной установки. ТР — конкретный режим, совокупность управляемых и наблюдаемых параметров, характеризующих работы установки. Конечно же, установка работает в каком-то конкретном ТР (в пределах НТР). Рекомендации системы заключаются в переходах на другие ТР, которые также находятся в пределах НТР. Я не встречал такого, чтобы НТР состоял только из одного ТР.
Уже ответил — рекомендации работают строго в пределах регламента. Бывает, конечно же, и такое, что рекомендации упираются в предельные значения НТР в течение продолжительного времени (это пример не из O&G), в этом случае у самого владельца процесса могут возникнуть мысли или о внесении изменений в регламент, или о пересмотре целевой функции, которая оптимизируются (не учли какие-то долгосрочные эффекты или они имеют малый вес). В любом случае, это повод задуматься.
И да, как я уже сказал, скорее всего разные подходы должны слиться в один, но пока каких-то конкретных успехов тут нет ни у одной из сторон. Пока есть намерения и декларации :)
Проблем несколько — а) непрерывный контроль понимающим человеком — утопия, даже раз в полчаса подходить и смотреть/корректиррвать не у всех получается в силу совершенно разных причин, б) понимающий человек крайне быстро, со скоростью пропорциональной уровню понимания, идет вверх по должностям и перестает заниматься оперативным управлением установки, в) регламенты большинства предприятий устроены так, что операторы, которые действительно сидят и смортят на показания датчиков, отвечают за работу вверенной им установки (т.е. по оператору (точнее, обычно нескольким) на установку) только в пределах ее работы в заданных технологических режимах. Оптимальность текущего режима, не говоря уже о всем процессе, их не волнует, если говорить грубо.
Что касается логики работы самого процесса или установки — да, порой она бывает достаточно простая. Но почти всегда даже в самом простом процессе вылезает огромное количество нюансов, если вы хотите не просто смоделировать его работу, а управлять им, по возможности, оптимально. Там вылезают вопросы стоимости сырья (если используется разное), вопросы снижения ресурса оборудования из-за работы вблизи технологических режимов и т.п. Тут фокус сложности смещается с модели самого процесса (который действительно бывает простым) на процесс принятия решений/управления.
Неправильно. Нет цели получить новые знания как таковой. Есть цель построить две модели (в концепции RL они совмещены):
1. Модель процесса, которая а) учитывает известную физику процесса, б) достаточно точно воспроизводит процесс на доступных данных
2. Модель принятия решений с учетом того где мы находимся сейчас и какие возможности нам сейчас доступны, какой ожидаемый reward мы получим от каждого возможного действия.
Я изложил ровно обратное — не нарушать технологию. Для этого в т.ч. закладываются границы технологических режимов, за пределы которых рекомендации выходить не должны. Там есть нюансы, конечно же, с тем что если работать долго вблизи технологического предела, то это неизбежно приведет к более ранней поломке. Но обычно это также учитывается, правда чуть более тупо — бизнес-правилами (куда ж без них) в целевой функции модели принятия решений.
Разумеется, что это учтено на уровне физической модели, плюс можно было бы дополнительно перестраховаться, выкрутив long- и short-term reward'ы (но мы пока обошлись без этого).
В общем и целом, с точки зрения назначения — у APC и наших разработок оно одно и тоже — управлять (по возможности оптимально) процессом производства.
Различия такие:
А вообще, я считаю, что в один прекрасный момент оба подхода должны соединиться в один -наши или аналогичные решения должны перепрыгнуть на контроллер. Или остаться жить на серверах, а контроллеры стать простыми исполнительными механизмами. Но до тех пор, пока будет сильно разниться степень автоматизации промышленности, будут жить оба подхода.
Хотя RapidMiner Server и позволяет строить отчеты, но BI полноценный он заменить не может.
Потом увидел, что даже попсовый Gartner в своем Hype Cycle 2015 года убрал «BigData» (кстати, теперь там появился «Machine Learning»).
Похоже ажиотаж наконец-то начинает стихать.
А какие бизнес-задачи решаете или решали, не могли бы рассказать коротенько, если не коммерческая тайна, конечно?
Как приходите к технической постановке задачи на исследование/разработку? Бизнес что-то спускает или сами что-то генерите? Формируются какие-то бизнес-требования и критерия качества? Как результаты ваших разработок и исследований до конкретных действий доходят?
Был бы признателен, если поделитесь своими соображениями и опытом на это счет.
Вы выводите вопрос в плоскость «opensource vs proprietary». Почему вообще эти глупые люди вокруг платят за софт, а не используют опенсорс? Почему у того же SAS 70 тысяч клиентов, они что дураки все, можно же на R/Python/etc все самому написать? Почему же люди покупают Cloudera и HortonWorks, а не используют Apache Hadoop?
Скорость разработки, удобство использования пользователями, управление правами доступа из коробки, оптимизации производительности, различные бесшовные интеграции из коробки, простота поддержки, разработка силами не ученых и математиков. Можете продолжить список.
Отдельное удовольствие – управлять разработкой команды из ученых и математиков. Я знаю несколько историй с печальным концом, начинавшихся со слов «класс, сейчас мы соберем ВМКшников и ШАДовцев, дадим им данные и будет у нас счастье».
По пальцам одной руки могу пересчитать бизнес-аналитиков, с которыми мне приходилось работать, и которые при этом хорошо владеют «математикой» в своей индустрии. При этом, поверьте, большинство бизнес-аналитиков отлично разбираются в предметной области и знают, что им и для чего нужно.
А хороший математик-программист – в большинстве случаев никудышный бизнес-аналитик.
Поэтому эти роли все нормальные организации и руководители, как правило, разносят если не в разные отделы, то на разных людей точно.
Лично мое впечатление – я не смог все, что мне было тогда нужно (года полтора назад дело было) реализовать на KNIME. Плюс приходилось костыли городить из базовых блоков и loop'ов на функционал, который, как мне кажется, должен был бы быть в продукте. Я конкретику привести не вспомню сейчас, могу поискать, может где-то стрим сохраненный остался.
Ну и RM приятнее гораздо в работе (имхо, естественно).
1. Вы можете взять исходники предыдущей версии и собрать сами RapidMiner без ограничений, но старый (версия 5.3).
2. Вы можете взять бесплатно Starter (уже собранный) текущей версии (6.3) – 1 Гб и без подключения к БД.
3. Вы можете попробовать триал текущей версии 14 дней – там нет этих ограничений.
4. И вы можете купить пункт (3) уже в долгое пользование.
Кого давит 1 Гб на процесс — собирайте код (или зарегистрируйтесь на сайте, потом можно скачать бинарники). Для большинства же малого бизнеса достаточно стартера, поскольку там функционал аналитики тот же. Если расчёт у вас ещё и разовый, вроде анализов результатов за год, то можно настроить процесс в Starter и взять триал, чтобы перемолотить данные. А потом решить, стоит покупать полную версию или нет.
Ограничения бесплатной 6-ой версии на текущую опенсорсную (5.3) не распространяются.
Однако, вы можете заметить, что 6-ая версия по сравнению с 5-ой сильно прибавила в функциональности, т.е. далеко не все вы сможете найти в опенсорсной версии.
А описанная вами «любительская» задача далека от медианы аналитических задач даже среднего бизнеса. Нет, SNA и deep learning это круто, конечно, но далеко от «everyday data science» большинства аналитиков и разработчиков.
Про удобство программирования на R и Python над визуальным интерфейсом — достаточно спорный тезис.
Да, и про кроссплатформенность я забыл упомянуть — RM работает на Windows, Linux и Mac. Причем все компоненты, и Studio, и Server.