Алгоритм відповідності переваг


12

Є цей побічний проект, над яким я працюю, де мені потрібно структурувати рішення наступної проблеми.

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

Деякі складні аспекти проблеми:

  1. Список атрибутів не є кінцевим. Покупця може зацікавити дуже конкретна характеристика або якийсь дизайн, що є рідкісним серед населення, і я не можу передбачити. Попередньо не можна перерахувати всі атрибути;

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

Будь-яка пропозиція, як підійти до цієї проблеми та вирішити її автоматизованим способом?

Я також вдячний, якщо можливо, деякі посилання на інші подібні проблеми.


Чудові пропозиції! Багато подібності в тому, як я думаю підходити до проблеми.

Основне питання щодо відображення атрибутів полягає в тому, що рівень деталізації, до якого повинен бути описаний товар, залежить від кожного покупця. Візьмемо приклад автомобіля. Продукт "автомобіль" має багато-багато атрибутів, які варіюються від його продуктивності, механічної структури, ціни тощо.

Припустимо, я просто хочу дешевий автомобіль або електромобіль. Гаразд, це легко зробити карту, оскільки вони представляють основні особливості цього продукту. Але скажімо, наприклад, що я хочу автомобіль з коробкою передач Dual-Clutch або фарами Xenon. Добре, що в базі даних може бути багато машин із цими атрибутами, але я б не просив продавця заповнювати цей рівень деталізації свого товару до того, як інформація про те, що хтось їх шукає. Така процедура вимагає від кожного продавця заповнити складну, дуже детальну форму, просто спробувати продати свій автомобіль на платформі. Просто не буде працювати.

Але все ж моє завдання полягає в тому, щоб спробувати бути максимально детальним у пошуку, щоб зробити хороший збіг. Тож, як я думаю, це відображення основних аспектів товару, тих, які, мабуть, актуальні для всіх, щоб звузити дегрупу потенційних продавців.

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

Запропоновані критерії зважування великі. Це дозволяє мені оцінити рівень, на який продавець відповідає потребам покупця. Частина масштабування може бути проблемою, оскільки важливість кожного атрибуту змінюється від клієнта до клієнта. Я думаю про те, щоб використовувати якесь розпізнавання шаблону або просто попросити покупця ввести рівень важливості кожного атрибута.

Відповіді:


9

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

По-друге, я не думаю, що вам потрібно вважати, що список атрибутів не є скінченним. Стандартний та інтуїтивно зрозумілий підхід полягає у поданні кожного атрибуту як індивідуального виміру у векторному просторі. Кожен продукт тоді просто точка в цьому просторі. У цьому випадку, якщо ви хочете динамічно додати більше атрибутів, вам просто доведеться переставити вектори продукту в новий простір функцій (з додатковими розмірами).

При такому поданні продавець - це точка у просторі функцій з атрибутами товару, а покупець - це точка у тому ж просторі функції з атрибутами переваг. Завдання полягає в тому, щоб знайти найбільш подібну точку покупця для даної точки продавця.

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

Для дуже великих розмірів даних ви можете скористатися ІЧ-підходом. Індексуйте набір продавців (тобто атрибути товару), розглядаючи кожен атрибут як окремий термін, а термін-вага встановлюється на значення атрибута. Запит у цьому випадку - покупець, який також кодується у терміні простору як вектор запиту з відповідними ваговими термінами. Крок пошуку поверне вам список найпопулярніших K збігів.


Райт. Основне питання тут - кількість розмірів, тобто рівень деталізації, який мені потрібно використовувати. Чи можете ви пояснити мені "ІЧ-підхід".
RD

1
Під ІР я мав на увазі пошук інформації. Ви можете подумати, що документи (продавці) у вашій колекції та запит (покупець) - це всі вектори, вбудовані в термін (атрибут) простір. Як я вже говорив, для такого підходу потрібна задана кількість вимірів.
Дебасіс

7

Як було запропоновано, зашкалюють . Перш за все, виправте мене, якщо я помиляюся:

  • Для кожного унікального продукту існує лише кілька функцій;
  • Не існує остаточного списку функцій, і клієнти можуть додавати нові функції до своїх продуктів.

Якщо так, побудова повної таблиці характеристик продукту може бути обчислювально дорогою. І остаточна таблиця даних була б надзвичайно рідкою.

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

графік

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

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

    ціна_вага

  • для двійкових та не кількісних характеристик - просто логічне двозначне:

    особливість ваги

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

adj_w_1

adj_w_2

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

Майбутнє завдання: запровадити дешевий метод зважування країв на першому кроці :)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.