Algoritmo di corrispondenza delle preferenze


12

C'è questo progetto laterale a cui sto lavorando dove devo strutturare una soluzione al seguente problema.

Ho due gruppi di persone (clienti). Il gruppo Aintende acquistare e il gruppo Bintende vendere un determinato prodotto X. Il prodotto ha una serie di attributi x_ie il mio obiettivo è facilitare la transazione tra Ae Babbinando le loro preferenze. L'idea principale è quella di indicare a ciascun membro Aun corrispondente nel Bcui prodotto si adatta meglio alle sue esigenze, e viceversa.

Alcuni aspetti complicati del problema:

  1. L'elenco degli attributi non è finito. L'acquirente potrebbe essere interessato a una caratteristica molto particolare o ad un tipo di design, che è raro tra la popolazione e non posso prevederlo. Non è stato possibile elencare in precedenza tutti gli attributi;

  2. Gli attributi possono essere continui, binari o non quantificabili (es: prezzo, funzionalità, design);

Qualche suggerimento su come affrontare questo problema e risolverlo in modo automatizzato?

Gradirei anche alcuni riferimenti ad altri problemi simili, se possibile.


Ottimi suggerimenti! Molte somiglianze con il modo in cui sto pensando di affrontare il problema.

Il problema principale sulla mappatura degli attributi è che il livello di dettaglio a cui il prodotto deve essere descritto dipende da ciascun acquirente. Facciamo un esempio di un'auto. Il prodotto "auto" ha un sacco di attributi che vanno dalle sue prestazioni, struttura meccanica, prezzo ecc.

Supponiamo che io voglia solo un'auto economica o un'auto elettrica. Ok, è facile da mappare perché rappresentano le caratteristiche principali di questo prodotto. Ma diciamo, ad esempio, che voglio un'auto con trasmissione Dual-Clutch o fari allo xeno. Bene, ci potrebbero essere molte auto nella base di dati con questi attributi, ma non chiederei al venditore di inserire questo livello di dettaglio del loro prodotto prima che ci sia qualcuno che li sta cercando. Tale procedura richiederebbe ad ogni venditore di compilare un modulo complesso, molto dettagliato, solo per provare a vendere la sua auto sulla piattaforma. Non funzionerebbe.

Tuttavia, la mia sfida è cercare di essere il più dettagliato possibile nella ricerca per fare una buona partita. Quindi il modo in cui sto pensando è mappare gli aspetti principali del prodotto, quelli che sono probabilmente rilevanti per tutti, per restringere il gruppo di potenziali venditori.

Il prossimo passo sarebbe una "ricerca raffinata". Per evitare di creare un modulo troppo dettagliato, potrei chiedere ad acquirenti e venditori di scrivere un testo libero delle loro specifiche. Quindi utilizza un algoritmo di corrispondenza delle parole per trovare possibili corrispondenze. Anche se capisco che questa non è una soluzione adeguata al problema perché il venditore non può "indovinare" ciò di cui l'acquirente ha bisogno. Ma potrebbe avvicinarmi.

I criteri di ponderazione suggeriti sono ottimi. Mi consente di quantificare il livello al quale il venditore soddisfa le esigenze dell'acquirente. La parte di ridimensionamento potrebbe essere un problema, poiché l'importanza di ciascun attributo varia da client a client. Sto pensando di utilizzare un qualche tipo di riconoscimento del modello o semplicemente chiedere al compratore di inserire il livello di importanza di ciascun attributo.

Risposte:


9

Il mio primo suggerimento sarebbe quello di mappare in qualche modo gli attributi non quantificabili alle quantità con l'aiuto di adeguate funzioni di mappatura. Altrimenti, semplicemente lasciarli fuori.

In secondo luogo, non penso che sia necessario supporre che l'elenco di attributi non sia finito. Un approccio standard e intuitivo consiste nel rappresentare ogni attributo come una singola dimensione in uno spazio vettoriale. Ogni prodotto è quindi semplicemente un punto in questo spazio. In tal caso, se si desidera aggiungere dinamicamente più attributi, è sufficiente rimappare i vettori del prodotto nel nuovo spazio delle caratteristiche (con dimensioni aggiuntive).

Con questa rappresentazione, un venditore è un punto nello spazio delle caratteristiche con gli attributi del prodotto e un acquirente è un punto nello stesso spazio delle funzioni con gli attributi delle preferenze. Il compito è quindi quello di scoprire il punto acquirente più simile per un determinato punto venditore.

Se il tuo set di dati (ovvero il numero di acquirenti / venditori) non è molto grande, puoi risolverlo con un approccio del vicino più vicino implementato con l'aiuto di alberi kd.

Per dati di dimensioni molto grandi, è possibile adottare un approccio IR. Indicizza l'insieme dei venditori (ovvero gli attributi del prodotto) trattando ciascun attributo come un termine separato con il termine peso impostato sul valore dell'attributo. Una query in questo caso è un acquirente che è anche codificato nello spazio dei termini come vettore di query con pesi dei termini appropriati. Il passaggio di recupero ti restituirà un elenco delle migliori corrispondenze K più simili.


Wright. Il problema principale qui è il numero di dimensioni, cioè il livello di dettaglio che devo usare. Potresti chiarirmi "approccio IR".
RD

1
Per IR intendevo il recupero delle informazioni. Potresti pensare che i documenti (venditori) nella tua raccolta e la query (un acquirente) siano tutti vettori incorporati in uno spazio di termini (attributo). Come ho detto, un tale approccio richiede un numero predefinito di dimensioni con cui lavorare.
Debasis,

7

Come suggerito, impazzendo . Prima di tutto, correggimi se sbaglio:

  • Esistono solo alcune funzionalità per ogni prodotto unico;
  • Non esiste un elenco di funzionalità definitive e i clienti sono in grado di aggiungere nuove funzionalità ai propri prodotti.

In tal caso, la creazione di una tabella completa delle caratteristiche del prodotto potrebbe essere costosa dal punto di vista computazionale. E la tabella dei dati finali sarebbe estremamente scarsa.

Il primo passo è restringere l'elenco dei clienti (prodotti) per la corrispondenza. Costruiamo un grafico bipartito, in cui i venditori sarebbero nodi di tipo 1 e gli acquirenti sarebbero nodi di tipo 2. Crea un vantaggio tra qualsiasi venditore e acquirente ogni volta che fanno riferimento a una funzione di prodotto simile, come nel seguente schizzo:

grafico

Utilizzando il grafico sopra, per ogni prodotto di un venditore unico puoi selezionare solo gli acquirenti che sono interessati a funzionalità che corrispondono al prodotto (è possibile filtrare almeno una funzionalità comune, abbinare l'intero set di funzionalità o impostare un livello di soglia). Ma certamente non è abbastanza. Il passaggio successivo consiste nel confrontare i valori delle funzionalità, come descritto dal venditore e dall'acquirente. Esistono molte varianti (ad esempio, k-più vicini-vicini). Ma perché non provare a risolvere questa domanda usando il grafico esistente? Aggiungiamo pesi ai bordi:

  • per funzioni continue (ad es. prezzo):

    price_weight

  • per funzionalità binarie e non quantificabili - solo logico bicondizionale:

    feature_weight

L'idea principale qui è di ridimensionare ogni funzione all'intervallo [0, 1]. Inoltre, possiamo utilizzare i coefficienti di funzionalità per determinare le funzionalità più importanti. Ad esempio, supponendo che il prezzo sia due volte più importante della disponibilità di alcune funzioni rare:

adj_w_1

adj_w_2

Uno dei passaggi finali è la semplificazione della struttura del grafico e la riduzione di molti bordi su un bordo con un peso pari alla somma dei pesi calcolati in precedenza di ciascuna funzione. Con una struttura così ridotta ogni coppia di clienti / prodotti potrebbe avere un solo bordo (nessun bordo parallelo). Quindi, per trovare l'offerta migliore per il venditore esatto, devi solo selezionare gli acquirenti collegati con bordi ponderati max.

Sfida futura: introdurre un metodo economico per ponderare i bordi al primo passo :)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.