мы часто видим «связанные элементы». Например, в блогах у нас есть связанные должности, в книгах у нас есть связанные книги и т. Д. Мой вопрос заключается в том, как мы скомпилируем эти релевантности? Если это всего лишь тег, я часто вижу связанные элементы, которые не имеют одного и того же тега. Например, при поиске «розового» связанный элемент может иметь «фиолетовый» тег.
У кого-нибудь есть идея?
Существует много способов вычисления сходства двух элементов, но для простого метода взгляните на коэффициент Jaccard.
http://en.wikipedia.org/wiki/Jaccard_index
Который есть: J (a, b) = пересечение (a, b) / union (a, b)
So lets say you want to compute the coefficient of two items: Item A, which has the tags "books, school, pencil, textbook, reading" Item B, which has the tags "books, reading, autobiography" intersection(A,B) = books, reading union(A,B) = books, school, pencil, textbook, reading, autobiography so J(a,b) = 2/6 = .333 So the most related item to A would be the item which results in the highest Jaccard Coefficient when paired with A.
Вот несколько способов:
item_id
и related_item_id
, затем создайте интерфейс для вставки соединений. Полезно связать два элемента, которые связаны друг с другом, но не имеют сходства или не относятся к одной и той же категории / тегу (или в таблице без рубрики). Пример: ванна и резиновые утки Чтобы получить простой список связанных элементов на основе тегов, основные решения выглядят следующим образом:
3 таблицы, один с элементами, один с тегами и один с соединением. Таблица соединений состоит из двух столбцов: по одному для каждого идентификатора из остальных таблиц. Запись в таблице соединений связывает тег с элементом, помещая их соответствующие идентификаторы в строку.
Теперь, чтобы получить список связанных элементов.
выберите все элементы, которые имеют хотя бы один тег с исходным элементом. не забудьте взять теги вместе с элементами, а затем использовать простой механизм оценки, чтобы определить, какой элемент разделяет большинство тегов с оригинальным. каждый тег увеличивает отношение-релевантность на единицу.
В зависимости от ваших привычек пометки, возможно, было бы разумно добавить некоторый контр-механизм, чтобы предотвратить добавление значительных перекрывающих тегов. для достижения этого вы могли бы придать больший вес метокам ниже определенного порога приборов. Порог, который обычно хорошо работал для меня, – total_number_of_tag_appliances / total_number_of_tags, что приводит к среднему числу устройств. Если счетчик тегов меньше среднего, отношение-релевантность увеличивается вдвое.
Это может быть больше, чем тег, например, он может быть средним для каждой работы, появляющейся в абзаце, а затем заголовков и т. Д.
Я бы сказал, что они используют онтологию для того, что добавляет в приложение более интересные функции.
он также может быть основан на «люди, которые купили эту книгу, также купили»
Независимо от того, как вам, вам понадобится некоторое количество связей между вашими предметами, и в основном они будут сделаны людьми
Это моя реализация (GIST) индекса Jaccard с PostgreSQL и Ruby on Rails …
Вот реализация индекса jaccard между двумя текстами на основе биграмм. https://packagist.org/packages/darkopetreski/textcategorization