Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
А на практике проверялось?
Скоро будет проверено на практике. Пишу универсальный «движок» для сравнения фильмов, а-ля «фильм наподобие ___». Планирую выложить его на bitbucket для всех желающих.
Я добавил фичу вычисляющую реальную среднюю ошибку пользователей. То есть подсосывать время от времени объекты с известными атрибутами и сравнивать насколько оценка пользовталей коррелирует.
Да, так можно и вычислять пользователей, которые голосуют неправильно, и скорректировать вес их голоса.
В итоге может получиться динамическая самоорганизующаяся экспертная система.
В итоге может получиться динамическая самоорганизующаяся экспертная система.
Или пользователи будут ставить метку похожие на два телефона потому что оба телефона красного цвета а не потому что у обоих есть фонарик.
И такое тоже будет, согласен с вами, и пользователи тут правы — оба телефона красные, и этим они тоже похожи. И кто-то же должен определить что этот телефон — красный, задача администратора — импортировать набор товаров на сайт, он может это делать не глядя, просто проверив что все данные, включая фотографии и начальные описания импортировались верно.
И если уж обобщать, то все телефона — телефоны, следовательно, между всеми объектами есть нечто общее.
Однако, я верю в коллективный разум, и в то, что люди определяют похожие свойства не только по внешним параметрам, но и по функциональности.
И если уж обобщать, то все телефона — телефоны, следовательно, между всеми объектами есть нечто общее.
Однако, я верю в коллективный разум, и в то, что люди определяют похожие свойства не только по внешним параметрам, но и по функциональности.
Хм, выявим о товаре необходимые свойства по похожести, а кто их заполнит значениями? Как с помощью сравнения о фильме будет заполнена информация об актерах, наградах, сборах, трейлер? Можно ещё примеры практического применения?
Актеры, сборы, трейлеры — тут вы правы, такая информация нуждается в предварительном заполнении. Но метки- классификаторы содержимого вполне могут проставляться автоматически.
Если речь идет о фильмах: Например, на AniDB (база аниме) для каждого аниме есть множество меток, содержащих информацию и о сюжете, и о жанрах (пример). Соответственно, при добавлении нового объекта в базу, если ему присвоить все возможные метки и последовательно сравнить по предложенному алгоритму с уже известными объектами, мы сможем автоматически найти пересечения меток.
Чем больше меток проставлено изначально для известных объектов, тем точнее типизация.
Логика тут простая: если объект X похож на объект A и объект B, и не похож на объект C, то, вычисляя пересечения этих объектов, мы получаем подмножество, в которое входит некоторое количество общих свойств. Собственно, это и есть то, что мы вычисляем.
Если речь идет о фильмах: Например, на AniDB (база аниме) для каждого аниме есть множество меток, содержащих информацию и о сюжете, и о жанрах (пример). Соответственно, при добавлении нового объекта в базу, если ему присвоить все возможные метки и последовательно сравнить по предложенному алгоритму с уже известными объектами, мы сможем автоматически найти пересечения меток.
Чем больше меток проставлено изначально для известных объектов, тем точнее типизация.
Логика тут простая: если объект X похож на объект A и объект B, и не похож на объект C, то, вычисляя пересечения этих объектов, мы получаем подмножество, в которое входит некоторое количество общих свойств. Собственно, это и есть то, что мы вычисляем.
То есть практичность только в классификации (категоризации)?
Из первых абзацев статьи складывается картина, что администратор совсем не понимает, что за нечто добавляет на сайт. Может, только название или картинку этого нечто знает, а далее пользователи через сравнения определят, что это нечто автомобиль с турбонадувом X78 и болтиком с криволинейной резьбой в фиксаторе магнитных ускорителей. Ну и сотню других свойств :) Вот и задумался, как же через сравнения о товаре будет добавлена исчерпывающая информация, как будут добавлены уникальные свойства?
Из первых абзацев статьи складывается картина, что администратор совсем не понимает, что за нечто добавляет на сайт. Может, только название или картинку этого нечто знает, а далее пользователи через сравнения определят, что это нечто автомобиль с турбонадувом X78 и болтиком с криволинейной резьбой в фиксаторе магнитных ускорителей. Ну и сотню других свойств :) Вот и задумался, как же через сравнения о товаре будет добавлена исчерпывающая информация, как будут добавлены уникальные свойства?
Часть свойств, сами понимаете, невозможно так добавить. Но вот вычислить похожие объекты без муторного забивания их свойств — да, возможно.
Есть еще, кстати, возможность определять свойства объектов на основе отношения пользователя к ним.
Например: та же база фильмов. Зарегистрированные пользователи нажимают «нравится». Для каждого пользователя формируется перечень меток фильмов, которые ему нравятся, тем же методом пересечения. Теперь, если пользователь отметил неизвестный нам фильм, мы с некоторой вероятностью можем судить о его содержании и метках. Чем больше пользователей — тем больше точность.
Есть еще, кстати, возможность определять свойства объектов на основе отношения пользователя к ним.
Например: та же база фильмов. Зарегистрированные пользователи нажимают «нравится». Для каждого пользователя формируется перечень меток фильмов, которые ему нравятся, тем же методом пересечения. Теперь, если пользователь отметил неизвестный нам фильм, мы с некоторой вероятностью можем судить о его содержании и метках. Чем больше пользователей — тем больше точность.
Думаю вероятность эта будет несильно велика. Более-менее правомерно сделать предположение что если из двух объектов с сильно пересекающимся набором свойств один понравился, то понравится и другой, но вот делать выводу о свойствах одного по тому что понравился другой, очень опрометчиво. Как минимум нужно иметь значительный набор объектов, который понравился одному пользователю, выделить статистически значимое подмножество нравящихся значений свойств для него лично, и уже потом сравнивать оцениваемый объект с этим подмножеством.
Вы правы, нужен достаточно большой объем данных, и несколько пользователей, поставивших несколько «лайков»
Чем больше объем информации, тем точнее будет прогноз.
Про пересечение свойств в «лайках» одного пользователя: я исхожу из того, что у каждого человека есть свой набор предпочтений в, например, фильмах. Если такой человек «лайкнул» штук 20 фильмов, для которых у нас есть хороший набор меток (не просто, например «фантастика», а более подробный, типа: «роботы», «искусственный интеллект», «космос», «андроиды», «путешествия во времени» и т.п.), то мы сможем вычислить набор его предпочтений. Конечно, не все метки будут повторяться, но мы сможем вычислить их наличие и веса.
Далее, как только несколько пользователей «лайкнут» неизвестный нам фильм, мы сможем пересечь их предпочтения, где-то да они совпадут, вот 100% гарантия.
Надо только выяснить необходимый порог для этого, чьи голоса учитывать (какой минимальный порог «лайков» для каждого пользователя).
Чем больше объем информации, тем точнее будет прогноз.
Про пересечение свойств в «лайках» одного пользователя: я исхожу из того, что у каждого человека есть свой набор предпочтений в, например, фильмах. Если такой человек «лайкнул» штук 20 фильмов, для которых у нас есть хороший набор меток (не просто, например «фантастика», а более подробный, типа: «роботы», «искусственный интеллект», «космос», «андроиды», «путешествия во времени» и т.п.), то мы сможем вычислить набор его предпочтений. Конечно, не все метки будут повторяться, но мы сможем вычислить их наличие и веса.
Далее, как только несколько пользователей «лайкнут» неизвестный нам фильм, мы сможем пересечь их предпочтения, где-то да они совпадут, вот 100% гарантия.
Надо только выяснить необходимый порог для этого, чьи голоса учитывать (какой минимальный порог «лайков» для каждого пользователя).
я исхожу из того, что у каждого человека есть свой набор предпочтений в, например, фильмах.
Ложное предположение. Вернее как, человеку могут нравится разные фильмы. Вот есть у него 100 лайкнутых «роботов» и 100 лайкнутых «ниндзя» (причем ни одного «робоы-ниндзя» для простоты) — лайкнул он 201 фильм — это роботы или ниндзя?
Если метки будут скудными, то конечно, мы никак не поймем что человеку нравится. Поэтому я и говорю, что нужен хороший набор меток. Вот, если интересно, на Чобиты (AniDB), типичное описание:
я их скопировал как есть, сорри за «кашу». Вот что я имел в виду, говоря «хороший набор меток». Это — пример неплохого набора меток. Я бы его увеличил еще на 30-50%, но и этого достаточно.
И, кстати, для понимания пристрастий пользователя нужно считать не просто пересечения и вычитать несовпадения, а назначать каждой метке ее вес.
Да, это большой объем данных. Это — минус. Плюс состоит в том, что мы экономим время живого человека, которому, например нужно платить деньги за то, чтобы он посмотрел кино и вбил какое-то количество тегов — и не факт что набор будет верным. Опять же, подобные вычисления делаются не в рил-тайме, это может быть некий фоновый процесс, на slave-базе.
Скрытый текст
Android
Angst
Asia
College
Comedy
Conspiracy
Earth
Ecchi
Japan
Lingerie
Nopan
Nosebleed
Nudity
Original Work: Manga
Pantsu
Plot Continuity
Romance
School Life
Sci-Fi
Seinen
Slapstick
Sudden Girlfriend
Appearance Teacher x Student
Time: Future
Virtual Reality
artificial intelligence
beach episode
boy meets girl
broadcast
cropped to 4-3
character that only says own name
computer
Do Androids Dream of Electric Sheep?
drama
forbidden love
grail in the garbage
gynoid
head
patting
human-android relations
ideal woman
male protagonist
multiple couples
overly cute catchphrase
philosophical
robofetish-kun
RPG elements
sentou episode
symbolism
Angst
Asia
College
Comedy
Conspiracy
Earth
Ecchi
Japan
Lingerie
Nopan
Nosebleed
Nudity
Original Work: Manga
Pantsu
Plot Continuity
Romance
School Life
Sci-Fi
Seinen
Slapstick
Sudden Girlfriend
Appearance Teacher x Student
Time: Future
Virtual Reality
artificial intelligence
beach episode
boy meets girl
broadcast
cropped to 4-3
character that only says own name
computer
Do Androids Dream of Electric Sheep?
drama
forbidden love
grail in the garbage
gynoid
head
patting
human-android relations
ideal woman
male protagonist
multiple couples
overly cute catchphrase
philosophical
robofetish-kun
RPG elements
sentou episode
symbolism
я их скопировал как есть, сорри за «кашу». Вот что я имел в виду, говоря «хороший набор меток». Это — пример неплохого набора меток. Я бы его увеличил еще на 30-50%, но и этого достаточно.
И, кстати, для понимания пристрастий пользователя нужно считать не просто пересечения и вычитать несовпадения, а назначать каждой метке ее вес.
Да, это большой объем данных. Это — минус. Плюс состоит в том, что мы экономим время живого человека, которому, например нужно платить деньги за то, чтобы он посмотрел кино и вбил какое-то количество тегов — и не факт что набор будет верным. Опять же, подобные вычисления делаются не в рил-тайме, это может быть некий фоновый процесс, на slave-базе.
Могу сказать про себя: мне нравятся разные фильмы. я люблю и «Кошмар на улице вязов», и «Титаник» и «Искусственный интеллект», «Зеленый слоник», например тоже мне понравился, и массу разных других направлений и жанров, которые вроде бы никак друг с другом не связаны. Но, тем не менее, если собрать все фильмы, которые мне понравились, то можно найти некоторые закономерности и перевесы в определенных метках. Более чем уверен, что на основе моих «лайков» можно узнать мои предпочтения, какие именно аспекты мне лично нравятся.
Соответственно, пересекая мои интересы с интересами других людей, которым тоже понравился неизвестный (неопределенный в нашей системе) фильм, мы можем найти точки пересечения, просто потому что они будут. А если их нет — значит, у нас был плохой набор меток, и его надо расширять. Хорошая новость в том, что данное решение может работать «постфактум», то есть, если мы понимаем что пересечений нет, то добавляем метки и снова делаем расчет.
Соответственно, пересекая мои интересы с интересами других людей, которым тоже понравился неизвестный (неопределенный в нашей системе) фильм, мы можем найти точки пересечения, просто потому что они будут. А если их нет — значит, у нас был плохой набор меток, и его надо расширять. Хорошая новость в том, что данное решение может работать «постфактум», то есть, если мы понимаем что пересечений нет, то добавляем метки и снова делаем расчет.
Еще примеры практического применения: сравнение музыкальных композиций.
Или книги, похожие на фильмы.
Или сравнение авторов (кто из писателей похож по стилю на, например, Стивена Кинга).
Или книги, похожие на фильмы.
Или сравнение авторов (кто из писателей похож по стилю на, например, Стивена Кинга).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Типизация (определение свойств) объекта руками пользователей сайта