Perché l'ingegneria delle funzioni funziona?

20

Recentemente ho imparato che uno dei modi per trovare soluzioni migliori per i problemi di ML è attraverso la creazione di funzionalità. Si può fare per esempio sommando due funzionalità.

Ad esempio, possediamo due caratteristiche: "attacco" e "difesa" di un qualche tipo di eroe. Creiamo quindi funzionalità aggiuntive chiamate "totale" che è una somma di "attacco" e "difesa". Ora, ciò che mi sembra strano è che anche un duro "attacco" e "difesa" sono quasi perfettamente correlati con il "totale", ma otteniamo comunque informazioni utili.

Qual è la matematica dietro questo? O ho sbagliato a ragionare?

Inoltre, non è un problema, per i classificatori come kNN, che "totale" sarà sempre più grande di "attacco" o "difesa"? Quindi, anche dopo la standardizzazione avremo caratteristiche che contengono valori di intervalli diversi?

machine-learning feature-construction

— MrKadek750
fonte

La pratica di sommare due funzioni certamente non rappresenta "ingegneria delle caratteristiche" in generale.

— xji,

21

Metti in dubbio il titolo e il contenuto mi sembra non corrispondente. Se stai usando un modello lineare, aggiungi una funzionalità totale oltre all'attacco e la difesa peggiorerà le cose.

Innanzitutto risponderei al motivo per cui il lavoro di ingegneria delle funzioni in generale.

Un'immagine vale più di mille parole. Questa figura può darti alcune informazioni sull'ingegnerizzazione delle funzionalità e sul perché funziona ( fonte dell'immagine ):

I dati nelle coordinate cartesiane sono più complicati ed è relativamente difficile scrivere una regola / costruire un modello per classificare due tipi.
I dati nelle coordinate polari sono molto semplici: possiamo scrivere una semplice regola su per classificare due tipi. $r$

Questo ci dice che la rappresentazione dei dati conta molto. In determinati spazi, è molto più facile svolgere determinati compiti rispetto ad altri spazi.

Qui rispondo alla domanda menzionata nel tuo esempio (totale in attacco e difesa)

In effetti, l'ingegnerizzazione delle funzionalità menzionata in questa somma di esempi di attacco e difesa, non funzionerà bene per molti modelli come il modello lineare e causerà alcuni problemi. Vedi Multicollinearità . D'altra parte, tale ingegneria delle caratteristiche può funzionare su altri modelli, come l'albero decisionale / foresta casuale. Vedi la risposta di @ Imran per i dettagli.

Quindi, la risposta è che, a seconda del modello utilizzato, alcune funzionalità ingegneristiche aiuteranno alcuni modelli, ma non per altri modelli.

— Haitao Du
fonte

Non è necessario che la somma sia collineare con i dipendenti. Vedi ad esempio la mia risposta.

— Kodiologo il

15

Il tipo di modello che stiamo utilizzando potrebbe non essere molto efficiente nell'apprendimento di determinate combinazioni di funzionalità esistenti.

Ad esempio, considera il tuo esempio dove sono le funzionalità ae d, e stiamo usando un albero decisionale per prevedere un risultato binario che risulta essere se e se . $0$ $a+d<0$ $1$ $a+d\geq0$

Poiché gli alberi decisionali possono essere divisi solo lungo gli assi delle singole caratteristiche, il nostro modello finirà per provare a costruire una scala per adattarsi a una linea, che sarà simile a questa:

Come puoi vedere, questo non si generalizzerà perfettamente con i nuovi dati. Possiamo avere dei cerchi sopra la vera linea decisionale che sono sotto il nostro confine decisionale e viceversa per le croci.

Tuttavia, se aggiungiamo a+dcome funzionalità, il problema diventa banale per un albero decisionale. Può ignorare l'individuo ae le dcaratteristiche e risolvere il problema con un unico a+d<0ceppo decisionale.

Tuttavia, se stessi utilizzando la regressione lineare, il tuo modello sarebbe perfettamente in grado di apprendere senza aggiungere una funzionalità aggiuntiva. $a+d$

In breve, alcune funzionalità aggiuntive possono essere d'aiuto a seconda del tipo di modello che si sta utilizzando e si dovrebbe fare attenzione a considerare sia i dati che il modello quando si progettano le funzionalità.

— Imran
fonte

1

Questo è esattamente il punto. La scelta delle caratteristiche e la scelta del modello devono essere considerate insieme. È una trappola comune provare e ragionare sulla selezione delle caratteristiche senza considerare il tipo di modello utilizzato.

— Imran,

1

Per esempio, se si è tentato la stessa cosa con la regressione lineare allora ae dsarebbe sufficiente e l'aggiunta di a+duna funzione non avrebbe fatto la differenza.

— Imran,

Ho aggiornato la mia risposta per renderlo più esplicito.

— Imran,

1

Inoltre, la divisione sulla linea diagonale richiede una divisione. La scala che hai disegnato "consuma" sette spaccature.

— Accumulo il

3

Una caratteristica costruita come totalpuò ancora essere utile in modo predittivo se non è fortemente correlata con altre caratteristiche dello stesso modello. totalin particolare non è necessario che siano strettamente correlati con attacko defense. Ad esempio, se attackè (8, 0, 4) ed defenseè (1, 9, 6), allora la correlazione di totalcon attackè 0 e la correlazione di totalcon defenseè . $\frac{1}{7}$

Inoltre, non è un problema, per i classificatori come kNN, che "totale" sarà sempre più grande di "attacco" o "difesa"? Quindi, anche dopo la standardizzazione avremo caratteristiche che contengono valori di intervalli diversi?

Se vuoi standardizzare i tuoi predittori, dovresti farlo dopo che sono stati tutti costruiti.

— Kodiologist
fonte

1

è davvero vero? Certamente, in un semplice modello lineare, non lo è: la matrice [attack, defense, total]è ovviamente di grado 2. Potrei immaginare in qualcosa come un modello lineare penalizzato che potrebbe fare la differenza, ma si basa sull'intuizione piuttosto che lavorarci fino in fondo. Puoi spiegare perché se attacke se defensenon sono strettamente correlati total(cosa che accade quando attacke defensesono fortemente correlati negativamente), perché totalpuò essere utile?

— Cliff AB,

1

@CliffAB Con il senno di poi, ero un po 'loquace qui. Avevo ragione nel dire che una caratteristica costruita può essere utile quando non è fortemente correlata con altri predittori e che totalnon ha bisogno di essere fortemente correlata con attacko defense, ma non useresti mai due predittori e la loro somma nello stesso modello, a causa del lineare dipendenza, con implica una forte correlazione tra circa due dei tre.

— Kodiologo il

1

Per dare una risposta generale, l'ingegnerizzazione delle funzionalità nella maggior parte dei casi riguarda l'estrazione di funzionalità significative dai dati, quindi se dai maggiori informazioni al tuo modello, ovviamente dovrebbe comportarsi meglio. Supponiamo che i tuoi dati siano costituiti da indirizzi e-mail nel formato "nome.s cognome@dominio.country -code". Se le usassi così come sono nel tuo modello, ogni persona sarebbe caratterizzata da un'unica e-mail, quindi questo non ci direbbe molto. Ci direbbe solo che un'e-mail appartiene a una persona diversa da un'altra. Con l'ingegnerizzazione delle funzionalità, da tali indirizzi potresti estrarre informazioni su possibili generi (nome), origini familiari ed etnia (cognome), nazionalità (dominio) e molti altri - ti dà praticamente molte informazioni, no?

— Tim
fonte

1

Che cosa stai cercando di realizzare con il tuo totale "funzionalità" ? Se stai semplicemente confrontando gli eroi, l' attacco e la difesa potrebbero essere più utili. Se trovassi utile il tipo di build (quanto orientato offensivamente rispetto a quanto orientato sulla difensiva), forse l' attacco / difesa sarebbe più utile. O forse MyAttack - YourDefense è più utile.

Dipende davvero dal tuo obiettivo e si riduce a te iniettando ulteriori conoscenze nel problema in modo da poter ottenere risposte migliori. Potreste aver sentito la gente gettando intorno login e quadrato e il rapporto e tutti i tipi di modi si potrebbe fare caratteristiche, ma la linea di fondo è che "utile" dipende dal compito a portata di mano e coinvolge trasformare i dati che avete in un dominio in cui le decisioni sono più semplice.

— Wayne
fonte