Алгоритм сопоставления предпочтений

12

Есть этот побочный проект, над которым я работаю, где мне нужно структурировать решение следующей проблемы.

У меня есть две группы людей (клиентов). Группа Aнамеревается купить, и группа Bнамеревается продать определенный продукт X. Продукт имеет ряд атрибутов x_i, и моя цель состоит в том, чтобы облегчить транзакцию между Aи Bпутем сопоставления их предпочтений. Основная идея заключается в том, чтобы указать каждому члену Aсоответствующего, Bчей продукт лучше соответствует его потребностям, и наоборот.

Некоторые усложняющие аспекты проблемы:

  1. Список атрибутов не является конечным. Покупатель может быть заинтересован в особой характеристике или каком-либо дизайне, что редко встречается среди населения, и я не могу предсказать. Не могу предварительно перечислить все атрибуты;

  2. Атрибуты могут быть непрерывными, двоичными или не поддающимися количественному определению (например, цена, функциональность, дизайн);

Любое предложение о том, как подойти к этой проблеме и решить ее в автоматическом режиме?

Я также был бы признателен за ссылки на другие подобные проблемы, если это возможно.


Отличные предложения! Много общего в том, как я думаю о подходе к проблеме.

Основная проблема при сопоставлении атрибутов заключается в том, что уровень детализации, к которому должен быть описан продукт, зависит от каждого покупателя. Давайте возьмем пример автомобиля. Продукт «автомобиль» имеет множество атрибутов, которые варьируются от его производительности, механической структуры, цены и т. Д.

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

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

Следующим шагом будет «изысканный поиск». Чтобы избежать создания слишком подробной формы, я мог бы попросить покупателей и продавцов написать свободный текст их спецификации. А затем используйте некоторый алгоритм сопоставления слов, чтобы найти возможные совпадения. Хотя я понимаю, что это неправильное решение проблемы, потому что продавец не может «угадать», что нужно покупателю. Но может приблизить меня.

Предложенные критерии взвешивания - это здорово. Это позволяет мне количественно определить уровень, до которого продавец соответствует потребностям покупателя. Часть масштабирования может быть проблемой, потому что важность каждого атрибута варьируется от клиента к клиенту. Я подумываю использовать какое-то распознавание образов или просто попросить покупателя указать уровень важности каждого атрибута.

RD
источник

Ответы:

9

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

Во-вторых, я не думаю, что вам нужно предполагать, что список атрибутов не является конечным. Стандартный и интуитивно понятный подход заключается в представлении каждого атрибута как отдельного измерения в векторном пространстве. Каждый продукт - это просто точка в этом пространстве. В этом случае, если вы хотите динамически добавить больше атрибутов, вам просто нужно переназначить векторы продуктов в новое пространство признаков (с дополнительными измерениями).

В этом представлении продавец является точкой в ​​пространстве признаков с атрибутами продукта, а покупатель - точкой в ​​том же пространстве признаков с атрибутами предпочтения. Задача состоит в том, чтобы затем найти наиболее похожую точку покупателя для данной точки продавца.

Если ваш набор данных (т. Е. Число покупателей / продавцов) не очень велик, вы можете решить эту проблему с помощью подхода ближайшего соседа, реализованного с помощью деревьев kd.

Для данных очень большого размера вы можете использовать ИК-подход. Индексируйте набор продавцов (т. Е. Атрибуты товара), обрабатывая каждый атрибут как отдельный термин, а весу термина присваивается значение атрибута. В этом случае запросом является покупатель, который также закодирован в пространстве терминов как вектор запроса с соответствующими весами терминов. Этап поиска вернет вам список самых популярных совпадений.

Debasis
источник
Райт. Основным вопросом здесь является количество измерений, то есть уровень детализации, который мне нужно использовать. Не могли бы вы уточнить мне «ИК подход».
RD
1
Под IR я имел в виду информационный поиск. Вы можете подумать, что документы (продавцы) в вашей коллекции и запрос (покупатель) - это векторы, встроенные в пространство терминов (атрибутов). Как я уже сказал, такой подход требует заранее определенного количества измерений для работы.
Debasis
7

Как и предполагалось, схожу с ума . Прежде всего, поправьте меня, если я ошибаюсь:

  • Только несколько функций существуют для каждого уникального продукта;
  • Список конечных функций отсутствует, и клиенты могут добавлять новые функции в свои продукты.

Если это так, то создание полной таблицы характеристик продукта может потребовать значительных вычислительных ресурсов. И окончательная таблица данных будет крайне скудной.

Первым шагом является сужение списка покупателей (товаров) для сопоставления. Давайте построим двудольный граф, где продавцами будут узлы типа 1, а покупателями - узлы типа 2. Создайте грань между любым продавцом и покупателем каждый раз, когда они ссылаются на аналогичную функцию продукта, как показано на следующем рисунке:

график

Используя приведенный выше график, для каждого продукта уникального продавца вы можете выбрать только покупателей, которые заинтересованы в функциях, которые соответствуют продукту (можно отфильтровать хотя бы одну общую функцию, сопоставить полный набор функций или установить пороговый уровень). Но, конечно, этого недостаточно. Следующим шагом является сравнение значений характеристик, как описано продавцом и покупателем. Вариантов много (например, k-Nearest-Neighbours). Но почему бы не попытаться решить этот вопрос, используя существующий график? Давайте добавим веса к краям:

  • для непрерывных функций (например, цена):

    price_weight

  • для бинарных и не поддающихся количественной оценке характеристик - просто логическое условие:

    feature_weight

Основная идея здесь - масштабировать каждую функцию до интервала [0, 1]. Кроме того, мы можем использовать коэффициенты характеристик для определения наиболее важных характеристик. Например, если предположить, что цена вдвое важнее, чем доступность некоторой редкой функции:

adj_w_1

adj_w_2

Одним из последних шагов является упрощение структуры графа и уменьшение множества ребер до одного ребра с весом, равным сумме ранее рассчитанных весов каждого объекта. При такой сокращенной структуре каждая пара клиентов / продуктов может иметь только одно ребро (без параллельных ребер). Итак, чтобы найти лучшее предложение для конкретного продавца, вам просто нужно выбрать подключенных покупателей с максимально взвешенными краями.

Задача на будущее: внедрить дешевый метод взвешивания ребер на первом шаге :)

sobach
источник