Открыть список
Как стать автором
Обновить

Комментарии 25

Привет!

а все-таки только в ритейле целесообразно применять? Или в принципе в закупках, например?

Да в общем где угодно, по сути ж это парвила «встречаемости» значений друг с другом. Хоть в ритейле, хоть в закупках канцелярки.
А ведь я всегда подозревал, что кто-то в нашем безумном мире заморачивается подобными исследованиями.
Что-то подобное делал используя Deductor, но удивительных результатов не получал, хотя возможно просто мало времени этому процессу уделял (задача была с низким приоритетом).
Ну смотря какое удивление Вы ожидали:)

В принципе, часто коммонсенс справляется, если данные маленькие.
Ну смотря какое удивление Вы ожидали:)
Это я про заголовок)) Всё было довольно предсказуемо, без пива+подгузники: вот сегмент закупается домой (молоко <-> хлеб), а вот на природу поехали (уголь -> мясо) и т.д.
В принципе, часто коммонсенс справляется, если данные маленькие.
Данных много было (продуктовый ритейл >3 регионов в Сибири), просто никто не занимался ими… Мне дали учебную версию дедактора «на поковырять в свободное время», но в продакшн не запускали… Может быть там что-нибудь и выходящее за рамки было, но не довелось зафиксировать…
Ну все сильно зависит от конкретного клиента и задачи. В премиальном сегменте, например, хороший бандл получился, когда выяснилось, что покупают вместе мягкий сыр, мед и варенье:)

1) Charm является экспоненциальным алгоритмом в худшем случае. Рассмотрите квадратную матрицу размера n заполненую единицами кроме главной диагонали. У вас количество замкнутых itemsets будет экспонециально.
2) А как реально использовать результаты? Как проверить, что их использование приносит хоть какую-то ценность?

А как реально использовать результаты?
Кто-то покупает «x», но не покупает «y» — дайте ему персональную рекламу/скидку/предложение на чеке на товар «y».
Как проверить, что их использование приносит хоть какую-то ценность?
Делим группу тех, кто покупает «x», но не покупает «y» на две части.
С первой работаем — вторая контроль.
Через период времени смотрим на изменение показателя (суммы покупки/среднего чека/размера прибыли с покупателя).
Ответы очень банальны. А теперь так. У вас 10^10 ассоциативных правил с приемлимыми поддержкой, lift и достоверность. Из них за приемлимое время можете найти 10^8.

Чтобы сделать то что вы написали, вам необходимо выбрать лучшие, попробовать из них реализовать рек. систему. Разделив при этом на обучающее и тестовое множество и при этом ещё и получить результат существенно выше чем простое SVD.
с приемлимыми поддержкой, lift и достоверность


Корень зла именно тут:) важно определить, какой порог отсечения будет, для этого с клиентом согласовываестя трейд-офф между производительностью и желаемым объемом вывода. На совсем больших данных надо совсем другие инструменты юзать: FIUT, FiDoop, TPFP, например.
Ну в том числе поэтому и спросил. Кроме того в оффлайне это ещё сложнее использовать. Да и клиенты не понимают как устанавливать любые пороги, потому что часто за ними непонятный смысл, точнее его связь с реальностью.

А вот за интрументы в конце ответа спасибо. Никогда с ними не работал. Надо будет изучить.
Да и клиенты не понимают как устанавливать любые пороги


Ну это вот работа условного продакта\проджекта: объянить\уговороить
1) Charm является экспоненциальным алгоритмом в худшем случае. Рассмотрите квадратную матрицу размера n заполненую единицами кроме главной диагонали. У вас количество замкнутых itemsets будет экспонециально.


Колчиество да, но мы же про эффективность. Тут неплохие бенчи: pdfs.semanticscholar.org/fc59/bb528815efc84c2a08a3ad09f9ced8cc7508.pdf
Ну да, на реальных данных работает очень медленно. В оригинальной статье рассматривались конкретные выборки. На других экспонента. LCMv3.0 работает в разу лучше, но этого не перестаёт быть экспонециальной. Размер выхода огромен и в сложных случаях принципиально не считаем до нужной глубины.

Вы видели алгоритм CLOPE? Он именно про эту тему.

Да, он самый. Что про этих ребят скажете?


Иногда кластеризация дейтсвительно лучше справляется.

В плане? Не понял коммента. Т.е. А чем по Вашему является CLOPE? Разве не алгоритмами кластеризации категориальных объектов?

Что про этих ребят скажете?

А вот ничего не скажу:( Пробовать надо, честно, не пробовал.

В плане? Не понял коммента. Т.е. А чем по Вашему является CLOPE? Разве не алгоритмами кластеризации категориальных объектов?


Так я и говорю, что иногда алгоритмы кластеризации (в частности CLOPE, ROCK), справляются с такими задачками лучше, чем правила. Надо будет потестить. Можете, кстати, статью запилить про них, если знакомы с ними. Было бы круто:)

У меня есть готовая статья. Но руки не доходят до того, чтобы её выкатить. Я там показал, что CLOPE в некотором смысле эквиваленте оптимизации метрики в пространстве tf-idf (точнее, только tf). Также пробовал кластеризовать группы ВК (по пересечениям id участников). Если интересно, то я могу этим заняться и выложить её сюда, на хабр. Ссылку прилагаю https://github.com/Hedgehogues/CLOPE

У меня были мысли по поводу продолжения исследования этого алгоритма по нескольким причинам. Его авторы говорят в последних статьях о том, что он чертовски хорошо параллелится. Они заявляют, что в ряде задач он себя показывает лучше, чем аналоги. Для качественной работы метода нужно подбирать параметр отталкивания. Алгоритм неустойчив относительно этого веса. В связи с этим он должен модифицироваться.


P.s. Если на такие исследования будет спрос, то я с радостью сделаю несколько обзоров. Но когда я проходил курс Юрия Кашницкого (ODS), это был мой тьюториал. Но он не вызвал практически никакого интереса со стороны участников курса. Поэтому на ресерч я забил.

Но он не вызвал практически никакого интереса со стороны участников курса. Поэтому на ресерч я забил.


ИМХО нет тут никакой корреляции, в смысле между интересом к CLOPE\ROCK, и количеством лайков в слаке в группе ml course open :) Arules как тьюториал тоже не зашли, потмоу что, наверное, это не тьюториал:)

Так что заходите на слак на ods_habr, кидайте черновик всем на почитать.

Хорошо, спасибо за совет. Возьму на заметку. Наверное, решусь и кину.

Если посчитать lift для пива и подгузников по первой предложенной формуле, то получается 0.4 / (0.8 * 0.6) = 0.8(3). Где ошибка?
Спасибо за комментарий, косяк на нашей поляне :) поправили
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
ods.ai
Численность
5 001–10 000 человек
Дата регистрации

Блог на Хабре