Все кто пишет, что классическим архитектурам доверять нельзя, а блокчейну можно, как-то забывают о том, что владелец 50%+1 мощностей может поменять всю историю транзакций.
Этот риск немного ниже в крипте, хотя в основных криптах ТОП-3 владельца уже аккумулирували порядка 45%. Что им помешает объединиться для «великого кидка»?
А если говорить о блокчейне между компаниями, пусть таже ТНК, или о регуляторах, то там априори владение сконцентрировано изначально.
+ Как правильно было замечено автором, блокчейн — это не сама сеть, а люди и то, как / чем они взаимодействуют с сетью. Сколько уже было случаев взлома посредников, за счет чего компроментировалась вся сеть.
Так что единственное «преимущество» блокчейна — распределенность -> достоверность, под большим вопросом и ни чем не лучше в сравнении с грамотной организацией классической архитектуры.
Я не верю в блокчейн на столько же, на сколько сильно верит автор. И со мной солидарна статистика — блокчейн отстает уже на 2 года (!) в своей динамике роста, по сравнению с другими успешными хайп-технологиями-единорогами. ИМХО
Для хаба «машинное обучение» в статье описано только «для скор-карт используйте лог-регрессию и трансформируйте переменные»? Было бы полезно описать хотя бы шаги построения модели, какие были промежуточные результаты, как проходил feature engineering и feature selection, почему для второй модели был выбран RF, как проходил тюнинг RF и тд. и тп.
С acceptance rate 10% и gini модели в 86% + на базе RF проблема eject inference еще более была усугблена и модель, скороее всего, была переобучена: решения андеррайтеров принимались исключительно в «зеленой зоне» ИМХО. Было бы интересно также посмотреть анализ связи принятых решений и NPL — это позволит сразу понять на сколько acceptance rate 10% адекватный + имеет ли смысл строить модель на решение андеррайтера.
Подход в целом интересный, но очень не хватает деталей для такого хаба…
Идею понял. Ничего против survival analysis не имею, но немного смущает противопоставление…
Если компания определила, что реагировать на тревожный сигнал по сотруднику нужно за 4 месяца (а ей это придется делать для любой модели — врядли кто-то что-то будет делать, если модель дожития покажет вероятность увольнения через год-полтора), то ничто не мешает построить поведенческий бинарный классификатор на целевую переменную 4 месяца.
Либо классификатор представить в виде сгруппированной шкалы с нужным горизонтом (например, целевое событие с запасом через 6 месяцев), и как только сотрудник попадет по модели в «зону риска» — начать его усиленно мотивировать :)
В любом случае в основе обеих подходов лежат, как праивло, вероятности распределения по регрессорам. Анализ дожития просто делает еще один дополнтельный шаг — вектор вероятностей наступления вероятности :)
Кстати, если Вы работаете с этой системой на практике, было бы очень интересно посмотреть результаты бэктеста, а еще лучше А\Б бэктеста, а еще лучше — сансамблировать оба подхода. Тема для меня очень актуальная, т.к. прямо сейчас я заканчиваю проработку архитектуры аналогичной модели.
По карме плюсовать на пост не могу, но хотя бы в комментариях Вам большой +
Не совсем понятно, почему вы противопоставляете бинарную классификацию анализу дожития. Ведь результаты модели представляют собой не столько сами бины («черное-белое»), сколько непрерывные вероятности вхождения в каждый бин и регулируя кат-офф на непрерывном горизонте вы модете получить разные классификаторы.
Так же не очень понятно, как модели дожития справляются с предложенной проблемой вначале — адаптация к изменяющимся условиям?
Сейчас не могу уже найти, но встречал интересную интерпритацию модели дожития — предполагалось, на примере HR-кейса, что любой сотрудник в любом случае когда-то уволится с 100% вероятностью, главные вопрос — когда?, что и пытались смоделировать.
Компания EquBot запустила биржевой инвестиционный фонд AI Powered Equity ETF (тикер: AIEQ), портфель которого формируется с помощью технологии искусственного интеллекта IBM Watson. На ноябрь 2017 его совокупная доходность превышала индекс S&P 500
Я бы посоветовал автору почитать не только об анализе нормального распределения, но и конкретно о time series — стационарости, автокорреляции, дифференсах, шуме и тренде, ARMA/ARIMA моделях для начала.
Бэктестинг, безусловно, полезный инструмент, но абсолютно не решающий. Результаты бэктестинга на данных, по которым строилась модель, по-умолчанию покажут выше результаты, чем новые данные в будущем. Здесь более важно проверка модели на валидационых выборках — тех, которые вообще не учавствовали в обучении / тестировании.
Особенно этот вопрос становится интересным в примере time series — должна выбрка формироваться из непрерыных точек ряда или случайных? Если на обеих подходах валидация будет успешно, то тогда можно говорить о каком-то качестве модели…
R поддерживает около 7-ми парадигм, включая функциональную, процедурную и ООП.
Нет типов данных как таковых, есть внутренние режимы хранения данных и объединения объектов в иерархические структуры
Типы данных есть и их целых 7 — numeric, integer, complex, logical, character, NA, NULL. И каждый из этих типов может быть представлен в базовой структуре вектора (включая сам вектор, matrix, array, data.frame, list) + дополнительные структуры factor и formula + расширяемые структуры различных пакетов.
всё в нем может быть иметь имя и любые другие атрибуты что вы пожелаете им приписать
Т.к. базовая структура вектор, то атрибуты хранятся на его уровне — отдельный элемент вектора не может иметь свой отдельный аттрибут, он просто индексируется из векторного атрибута.
Вы никак не можете указывать никаких прототипов классов, объектов, интерфейсов (кроме набора параметров функций)
В объектах класса S4 вы можете все это сделать — определить слоты, прототипы и т.д.
Ну и дальше много чего написано исходя из предположения, что нет системы типов, хотя она по факту есть, но динамическая. Кстати возможна реализация и строго-типизированной системы через S4-объекты.
Для меня самым интересным и наглядным общедоступным примером feature engeneiring является задача Титаника. Можно просто почитать готовые работы на кегле и понять всю суть этого процесса — сколько всего полезного можно извлечь из простых, казалось бы, данных + заполнить пропуски одних параметров на основании других.
Полностью поддерживаю. Поти все европейские офисы нашей компании перешли на микс-систему: небольшие open-space, много маленьких комнат от 1 до 5 мест и переговорки разного размера. Работать одно удовольствие: хочешь уединится командой — пожалуйста, хочешь поработать сам в тишине — пожалуйста, хочешь посидеть в open-space и зарядиться микро-климатом — тоже пожалуйста.
Скажите, пожалуйста, какой размер команды разработки / поддержки? Не из праздного любопытства — от размера команды будет зависеть понимание масштаба поддержки. На сколько я понимаю по вашим предыдущим статьям, широко используется shiny и мне интересно как осуществляется поддержка и bug-fixing достаточно большой командой, учитывая практически полную связь бэка и фронта. В моем понимании каждый член команды должен знать архитектуру и функциональность практически ВСЕГО приложения и всех его частей для эффективной поддержки. В маленьких командах это может не быть проблемой, но в распределённых — большой вопрос…
Этот риск немного ниже в крипте, хотя в основных криптах ТОП-3 владельца уже аккумулирували порядка 45%. Что им помешает объединиться для «великого кидка»?
А если говорить о блокчейне между компаниями, пусть таже ТНК, или о регуляторах, то там априори владение сконцентрировано изначально.
+ Как правильно было замечено автором, блокчейн — это не сама сеть, а люди и то, как / чем они взаимодействуют с сетью. Сколько уже было случаев взлома посредников, за счет чего компроментировалась вся сеть.
Так что единственное «преимущество» блокчейна — распределенность -> достоверность, под большим вопросом и ни чем не лучше в сравнении с грамотной организацией классической архитектуры.
Я не верю в блокчейн на столько же, на сколько сильно верит автор. И со мной солидарна статистика — блокчейн отстает уже на 2 года (!) в своей динамике роста, по сравнению с другими успешными хайп-технологиями-единорогами. ИМХО
С acceptance rate 10% и gini модели в 86% + на базе RF проблема eject inference еще более была усугблена и модель, скороее всего, была переобучена: решения андеррайтеров принимались исключительно в «зеленой зоне» ИМХО. Было бы интересно также посмотреть анализ связи принятых решений и NPL — это позволит сразу понять на сколько acceptance rate 10% адекватный + имеет ли смысл строить модель на решение андеррайтера.
Подход в целом интересный, но очень не хватает деталей для такого хаба…
www_image-share.com/ipng-3682-137.html
А LIME вам чем-то не нравится? Как раз решает проблему чероного ящика, с некоторой погрешностью, конечно. Или Вы знаете какие-то подводные камни?
Вот, например, классификатор от Ping Wang:
Если компания определила, что реагировать на тревожный сигнал по сотруднику нужно за 4 месяца (а ей это придется делать для любой модели — врядли кто-то что-то будет делать, если модель дожития покажет вероятность увольнения через год-полтора), то ничто не мешает построить поведенческий бинарный классификатор на целевую переменную 4 месяца.
Либо классификатор представить в виде сгруппированной шкалы с нужным горизонтом (например, целевое событие с запасом через 6 месяцев), и как только сотрудник попадет по модели в «зону риска» — начать его усиленно мотивировать :)
В любом случае в основе обеих подходов лежат, как праивло, вероятности распределения по регрессорам. Анализ дожития просто делает еще один дополнтельный шаг — вектор вероятностей наступления вероятности :)
Кстати, если Вы работаете с этой системой на практике, было бы очень интересно посмотреть результаты бэктеста, а еще лучше А\Б бэктеста, а еще лучше — сансамблировать оба подхода. Тема для меня очень актуальная, т.к. прямо сейчас я заканчиваю проработку архитектуры аналогичной модели.
По карме плюсовать на пост не могу, но хотя бы в комментариях Вам большой +
Так же не очень понятно, как модели дожития справляются с предложенной проблемой вначале — адаптация к изменяющимся условиям?
Сейчас не могу уже найти, но встречал интересную интерпритацию модели дожития — предполагалось, на примере HR-кейса, что любой сотрудник в любом случае когда-то уволится с 100% вероятностью, главные вопрос — когда?, что и пытались смоделировать.
Особенно этот вопрос становится интересным в примере time series — должна выбрка формироваться из непрерыных точек ряда или случайных? Если на обеих подходах валидация будет успешно, то тогда можно говорить о каком-то качестве модели…
openCPU
AzureML
DeployR Open
yhat
Domino
Sense.io
Вот, наверное, самый простой пример:
Making Predictions over HTTP with R
R поддерживает около 7-ми парадигм, включая функциональную, процедурную и ООП.
Типы данных есть и их целых 7 — numeric, integer, complex, logical, character, NA, NULL. И каждый из этих типов может быть представлен в базовой структуре вектора (включая сам вектор, matrix, array, data.frame, list) + дополнительные структуры factor и formula + расширяемые структуры различных пакетов.
Т.к. базовая структура вектор, то атрибуты хранятся на его уровне — отдельный элемент вектора не может иметь свой отдельный аттрибут, он просто индексируется из векторного атрибута.
В объектах класса S4 вы можете все это сделать — определить слоты, прототипы и т.д.
Ну и дальше много чего написано исходя из предположения, что нет системы типов, хотя она по факту есть, но динамическая. Кстати возможна реализация и строго-типизированной системы через S4-объекты.
www.datacamp.com/community/tutorials/r-or-python-for-data-analysis
На РРС рынке казино и адалт уступают разве что таблеткам ;)