Визуализировать слои и посмотреть на каком слое получился результат. Это рабочая гипотеза ;)

Что почитать надо?

С. Хайкин

Окей

Сейчас гляну

Мы общались с ним 2 недели

а точно тебе нейросеть надо? я бы начал с чего-то типа дерева решений

Попробую, спасибо

Мне кажется, что есть некая последовательность "ритуальных танцев" которую пользователь совершает, перед тем как уйти.

Но как это приближает к ответу на вопрос "почему?"? Все-равно придется потом додумывать что означает эта последовательность действий

Но как это приближает к ответу на вопрос "почему?"? Все-равно придется потом додумывать что означает эта последовательность действий

Согласен. Это скорее указывает направление, в котором нужно искать причину. Возможно, у вас есть идеи как найти причину?

Согласен. Это скорее указывает направление, в котором нужно искать причину. Возможно, у вас есть идеи как найти причину?

У меня нет, я поэтому и спрашиваю =)

У меня нет, я поэтому и спрашиваю =)

Была идея просто накидать побольше сырых данных, сделать побольше слоёв нейросети и на выходе получить важные фичи. Возможно степень важности фич будет косвенно указывать на причину

Мы общались с ним 2 недели

?

Есть у кого идеи как подступиться к предсказанию ухода пользователя из платного аккаунта? По-английски Customer Churning. Пробовал разные подходы из гугла, в основном sliding window + RNN. Что-то не едут лыжи, сетка тренируется на 100 и предсказывает ересь.

По мне так сюда кластеризация просится какая-нибудь. И потом изучать, чем кластеры похожи, тут можно увидеть инсайты. Ну или логистическа многомерная регрессия какая-нибудь, я не знаю. А лучше и то и то посмотреть.

По мне так сюда кластеризация просится какая-нибудь. И потом изучать, чем кластеры похожи, тут можно увидеть инсайты. Ну или логистическа многомерная регрессия какая-нибудь, я не знаю. А лучше и то и то посмотреть.

Спасибо! Самая простая кластеризация, как мне кажется, сравнивать пользователей, по длительности платного аккаунта: короткие, средние, длинные. И смотреть,что у них общего/разного.

Спасибо! Самая простая кластеризация, как мне кажется, сравнивать пользователей, по длительности платного аккаунта: короткие, средние, длинные. И смотреть,что у них общего/разного.

Самая простая кластеризация - автоматическая. А потом смотреть, почему так кластеризовалось

Самая простая кластеризация - автоматическая. А потом смотреть, почему так кластеризовалось

Как я понимаю, интересные (для бизнеса) кластеры можно получить если количество фич будет большим?

Интересные кластеры можно получить, если они объективно существуют, то есть данные реально делятся на осмысленные группы. Как-то кластеризовать можно любые данные.

+1. Количество фич вторично

Интересные кластеры можно получить, если они объективно существуют, то есть данные реально делятся на осмысленные группы. Как-то кластеризовать можно любые данные.

А как можно вообще понять по каким признакам были сформированы эти кластеры?

Например, взять центр кластера и посмотреть значения фич в нем. А дальше классически - смотреть, какие фичи объясняют variance.

А как можно вообще понять по каким признакам были сформированы эти кластеры?

Зависит от алгоритма, использованного для кластеризации. Вообще советую посмотреть какие бывают для этого алгоритмы. Плюс, задачу можно начать решать не с кластеризации, а с метода главных компонент. К тому же, вообще не понимаю зачем копать в кластеризацию, если вам подходят бинарные модели, то есть логрегрессии ИМХО вполне достаточно, по крайней мере для начала.

Зависит от алгоритма, использованного для кластеризации. Вообще советую посмотреть какие бывают для этого алгоритмы. Плюс, задачу можно начать решать не с кластеризации, а с метода главных компонент. К тому же, вообще не понимаю зачем копать в кластеризацию, если вам подходят бинарные модели, то есть логрегрессии ИМХО вполне достаточно, по крайней мере для начала.

для генерации фичей, хотя бы

Зависит от алгоритма, использованного для кластеризации. Вообще советую посмотреть какие бывают для этого алгоритмы. Плюс, задачу можно начать решать не с кластеризации, а с метода главных компонент. К тому же, вообще не понимаю зачем копать в кластеризацию, если вам подходят бинарные модели, то есть логрегрессии ИМХО вполне достаточно, по крайней мере для начала.

вот мне тоже показалось, что для первоначальной задачи - понять, ЧТО объясняет принадлежность к группе - логрегрессия лучше всего.

когда я подумала немного над задачей, то есть)

когда я подумала немного над задачей, то есть)

Спасибо, попробую логрегрессию

когда я подумала немного над задачей, то есть)

Ксения, подскажите, а как лучше применить логрегрессию для time series data? У меня есть фичи, описывающие поведение пользователя в мобильном приложении по дням в течение года. Данные очень разрежены, то есть есть дни, когда приложение не использовалось. Насколько я понимаю, для логрегрессии мне надо сконструировать искусственные переменные, которые будут непрерывными: среднее время использования приложения, среднее количество использований за сессию и т.п.

Ксения, подскажите, а как лучше применить логрегрессию для time series data? У меня есть фичи, описывающие поведение пользователя в мобильном приложении по дням в течение года. Данные очень разрежены, то есть есть дни, когда приложение не использовалось. Насколько я понимаю, для логрегрессии мне надо сконструировать искусственные переменные, которые будут непрерывными: среднее время использования приложения, среднее количество использований за сессию и т.п.

Первая ссылка из гугла хорошая, имхо: http://stats.stackexchange.com/questions/263715/binary-classification-on-time-series-data ? И я бы в вашем случае data mining of time series погуглила еще бы на предмет того, что делать с отсутствующими точками, это специальный вопрос, я не сталкивалась, но верю, что уже миллион методов придумали.

Это 3 ссылка из гугла http://mlsurveys.s3.amazonaws.com/98.pdf

Ксения, подскажите, а как лучше применить логрегрессию для time series data? У меня есть фичи, описывающие поведение пользователя в мобильном приложении по дням в течение года. Данные очень разрежены, то есть есть дни, когда приложение не использовалось. Насколько я понимаю, для логрегрессии мне надо сконструировать искусственные переменные, которые будут непрерывными: среднее время использования приложения, среднее количество использований за сессию и т.п.

Такие переменные для логрегрессии конструировать не надо.

Ребята, а правильно ли было бы задавать тут вопрос о том как лучше организовать хранение данных?

У меня есть первоначальные данные в формате csv, на основе них форируются данные в других видах для удобства дальнешего использования. Сейчас всё просто лежит на диске на одной машине. Хочется: 1) распределённое решение, для отказоустойчивости и для того что бы использовать свободное место на нескольих машинах 2) иметь возможность обращаться к этому хранилищу из Spark 3) это менее приоритетно: иметь возможность хранить неструктурированные данные

А самое главное то забыл...Чего с данными то делать будешь? ;) Читать/писать/ как читать/как писать/ объемы? А то мож можно и копеечным не big data решением обойтись?

Там вон у людей проблемы террабайты в секунду надо писать ,например, что народ выдумывает как их оцифровать ..Ибо микросхем ацп таких нет...А у тебя что?

А самое главное то забыл...Чего с данными то делать будешь? ;) Читать/писать/ как читать/как писать/ объемы? А то мож можно и копеечным не big data решением обойтись?

Это вебсервис, все данные - это логи действий пользователей. Данные поступают на данный момент примерно 200 Гб в месяц, но будет больше, раза в два. Раз в сутки сейчас генерируется более удобные форматы данных на основе "сырых" и раз в месяц генерируются отчёты, никакого realtime.

Как долго хранить это добро надо?

Такие переменные для логрегрессии конструировать не надо.

Какие тогда надо?

хочется иметь такое решение в которое можно было бы сливать все данные всех вспомогательных сервисов (штук 10), и некоторые ротировать, а некоторые хранить "вечно"

После генерации отчетов данные нужны?

После генерации отчетов данные нужны?

первоначальные нет, а "более удобные структуры" ещё пару-тройку месяцев надо хранить

Какие тогда надо?

Чтобы не ухудшить модель, нужно оставить числовые переменные (любого типа) как есть.

Чтобы не ухудшить модель, нужно оставить числовые переменные (любого типа) как есть.

Нужно ли данные нормализовывать и что делать с периодами, когда данных нет - везде 0 ?

хочется иметь такое решение в которое можно было бы сливать все данные всех вспомогательных сервисов (штук 10), и некоторые ротировать, а некоторые хранить "вечно"

clickhouse вполне себе

clickhouse вполне себе

спасибо, почитаю, может что-нибудь ещё для ... альтернативы?)

Если вопрос денег не стоит или уложить в террабайт можно : vertica

Если вопрос денег не стоит или уложить в террабайт можно : vertica

ок, спасибо

спасибо, почитаю, может что-нибудь ещё для ... альтернативы?)

Для ваших объёмов подойдёт нормальная реляционная СУБД, clickhouse далеко не идеальное решение. Слишком многим он жертвует ради скорости.

Логи в СУБД - это роскошь по умолчанию ;)) логи базы, бекапы и т.д и тп

Потом замучаетесь приводить данные в нормальную форму. Для нормального пользования clickhouse нужно хорошее понимание СУБД, иначе потом повылазят косяки.

ERROR: S client not available

Для ваших объёмов подойдёт нормальная реляционная СУБД, clickhouse далеко не идеальное решение. Слишком многим он жертвует ради скорости.

Ну, кстати может быть и да, почему то про реляционные БД я даже не думал, а начал смотреть сразу в nosql

Нужно ли данные нормализовывать и что делать с периодами, когда данных нет - везде 0 ?

Нормализовать не нужно, к нулю ни в коем случае приводить нельзя!

Либо игнорировать такие данные в модели, либо сначала их дополнить на основе другой регрессионной модели.

Ну, кстати может быть и да, почему то про реляционные БД я даже не думал, а начал смотреть сразу в nosql

Файлы не самый плохой вариант для логов

Файлы не самый плохой вариант для логов

У меня куча серваков на которых диски недоиспользованы, поэтому захотелось все файлы куда-нибудь сунуть, как я уже писал выше, ради большего места хранение и надёжности

Файлы не самый плохой вариант для логов

Тоже да

У меня куча серваков на которых диски недоиспользованы, поэтому захотелось все файлы куда-нибудь сунуть, как я уже писал выше, ради большего места хранение и надёжности

Если файлы устраивают, посмотрите формат HDF, манипуляции с ним будут быстрее, чем с csv

Если файлы устраивают, посмотрите формат HDF, манипуляции с ним будут быстрее, чем с csv

ок, спасибо, как раз смотрю

Можно бинарные форматы использовать, типа feather

а кто нибудь сталкивался с задачай распозанавание производителей телефонов по картинке, например мне нужно выбрать все телефоны от huawei с какого сета

?

заказчик пробовал на visual-recognition-demo.mybluemix.net

но результаты довольно плохие

в какую строну можно посмотреть (тулзы, сервисы)

а выборка есть?

если есть то примеров реализации было много - первое что на ум приходит кегля от авито на классификацию по фоточкам

да, выборка есть

Наверное, лучше обучать нейросетку с нуля, предобученные модели на других датасетах могут оказаться бесполезными

Наверное, лучше обучать нейросетку с нуля, предобученные модели на других датасетах могут оказаться бесполезными

Интересно, что модель скажет про черный прямоугольник. Чей же он, кому принадлежит? Apple или Samsung?

С тыльной стороны есть кое-какие различия. Если экран включен, то интерфейсы тоже отличаются

У меня куча серваков на которых диски недоиспользованы, поэтому захотелось все файлы куда-нибудь сунуть, как я уже писал выше, ради большего места хранение и надёжности

Если вам нужны логи по которым можно делать запросы, в одном проекте мы делали logstash + elastic search (обязательно не менее 3ех нод!) Пару сотен ГБ держит нормально. Дальше упирается в размер оперативной памяти.

На Амазоне память можно докупить, но это стоит денег. Зато запросы почти реалтайм

Если вам нужны логи по которым можно делать запросы, в одном проекте мы делали logstash + elastic search (обязательно не менее 3ех нод!) Пару сотен ГБ держит нормально. Дальше упирается в размер оперативной памяти.

Спасибо, эта связка тоже интересовала. Вообще realtime на данный момент не нужен, но распределённость решения мне нравится