Selezione di caratteristiche simili a un albero decisionale a lunghezza fissa per ridurre al minimo le prestazioni di ricerca medie


9

Ho una query complessa utilizzata per cercare un set di dati per trovare . Ogni query impiega il tempo medio quindi il tempo complessivo nella ricerca lineare è. Posso suddividere una query in sottoquery più semplici q_i e trovare e dove . Ogni sottoquery è molto più veloce da calcolare, quindi nel complesso è più veloce trovare e quindi usare per trovare .S H esatto = { s S dove  Q ( s )  è True } t t | S | H circa = { s S q j ( s ) è True } H esattoH circa q i H circa Q H esattoQSHexact={sSwhere Q(s) is True}tt|S|Happrox={sSqj(s)is True}HexactHapproxqiHapproxQHexact

Ogni ha molti . La sovrapposizione tra differenti è alta. Sto cercando un modo per determinare una serie di domande fisse simili a un albero delle decisioni che minimizzano il tempo medio per trovare un H_exact, sulla base di un ampio campione di query di ricerca.q i Q q jQqiQqj

Per rendere questo più concreto, supponiamo che il set di dati contenga i 7 miliardi di persone nel mondo, e le complesse query sono cose come "la donna che vive nella casa rossa all'angolo del 5 ° e Lexington in una città che inizia con B."

La soluzione ovvia è controllare ogni persona nel mondo e vedere chi corrisponde alla query. Potrebbe esserci più di una di queste persone. Questo metodo richiede molto tempo.

Potrei pre-calcolare esattamente questa query, nel qual caso sarebbe molto veloce .. ma solo per questa domanda. Tuttavia, so che altre domande riguardano la donna che vive nella casa blu nello stesso angolo, l'uomo che vive nello stesso angolo, la stessa domanda ma in una città che inizia con C, o qualcosa di totalmente diverso, come "il re di Svezia ".

Invece, posso dividere la complessa domanda in una serie di insiemi più semplici ma più generali. Ad esempio, tutte le domande di cui sopra hanno una query basata sul ruolo di genere, quindi posso precompilare l'insieme di tutte le persone nel mondo che si considerano una "donna". Questa sottoquery non richiede praticamente tempo, quindi il tempo di ricerca complessivo diminuisce di circa 1/2. (Supponendo che per altre conoscenze sappiamo che un "re" svedese non può essere una "donna". Hatshepsut era una donna egiziana che era re.)

Tuttavia, a volte ci sono query che non sono basate sul genere, come "la persona che vive nell'ottava strada in una casa rossa in una città che inizia con A." Vedo che la sottoquery "vive in una casa rossa" è comune e pre-calcola un elenco di tutte quelle persone che vivono in una casa rossa.

Questo mi dà un albero decisionale. Nel solito caso, ogni ramo dell'albero decisionale contiene domande diverse e i metodi per selezionare i termini ottimali per l'albero decisionale sono ben noti. Tuttavia, sto costruendo un sistema esistente che richiede che tutte le filiali debbano porre le stesse domande.

Ecco un esempio di una possibile serie di decisioni finali: la domanda 1 è "la persona è una donna?", La domanda 2 è "la persona vive in una casa rossa?", La domanda 3 è "la persona vive in una città a partire da A o la persona vive in una città che inizia con B? ', E la domanda 4 è' la persona vive in una strada numerata? '.

Quando arriva una query , vedo se il suo corrisponde a una qualsiasi delle domande pre-calcolate che ho determinato. In tal caso, ottengo l'intersezione di quelle risposte e faccio la domanda su quel sottoinsieme di intersezioni. Ad esempio, se la domanda è "persone che vivono in una casa rossa su un'isola", allora scopri che "la persona vive in una casa rossa" è già pre-calcolata, quindi si tratta solo di trovare il sottoinsieme di coloro che vivono anche su un'isola.q i q j QQqiqjQ

Posso ottenere un modello di costo guardando un insieme di molti e controllare per vedere la dimensione del corrispondente . Voglio ridurre al minimo la dimensione media di .QHapproxHapprox

La domanda è: come posso ottimizzare la selezione di possibili per rendere questo albero decisionale fisso? Ho provato un GA ma è stato lento a convergere. Probabilmente perché il mio spazio delle funzionalità ha pochi milioni di possibili . Ho escogitato un metodo avido, ma non sono contento del risultato. Anch'esso è molto lento e penso di ottimizzare la cosa sbagliata.q jqjqj

Quale ricerca esistente dovrei cercare idee?


I tuoi dati sono fissi? Hai intenzione di aggiungere altri esempi? Se non è meglio, prova a costruire l'albero delle descrizioni iniziando con la sottoquery con l' entropia con le informazioni più alte . Puoi anche scegliere qualche entropia minima dove fermare le descrizioni basate sull'albero e cercare con | S | .t quando S è abbastanza piccolo.
Anton,

Risposte:


1

La soluzione che ho trovato (ho posto la domanda) è usare la codifica sovrapposta, e più specificamente, una variante di Zatocoding che ha un supporto migliore per i descrittori gerarchici.

Il metodo che ho usato deriva da 'Un design efficiente per la ricerca di strutture chimiche. I. The Screens ', Alfred Feldman e Louis Hodes, J. Chem. Inf. Comput. Sci., 1975, 15 (3), pp 147-152.

La soluzione non gerarchica è esaminare la densità delle informazioni. A ciascun descrittore verranno assegnati i bit dove è la frequenza nel set di dati ( f_i <= 1.0). Calcola il numero totale di bit (la dimensione dell'albero decisionale) usando dove è il fattore di compressione Mooers 0.69 (da ). Dopo aver determinato il numero totale di bit da utilizzare, selezionare casualmente i bit per ciascun descrittore per l'assegnazione dei bit.si=log2(fi)fi0<DD=(sifi)/McMcloge2si

La soluzione gerarchica di Feldman e Hodes sostituisce per i descrittori che sono un sottoinsieme di altri descrittori. In tal caso, utilizzare dove è la frequenza del genitore meno frequente. Inoltre, quando si esegue l'assegnazione dei bit, non selezionare i bit che vengono utilizzati anche dall'assegnazione dei bit del genitore.s i = - l o g 2 ( f i / g i ) g isi=log2(fi)si=log2(fi/gi)gi

C'è ancora un problema su come trovare i descrittori giusti, ma sarà specifico per il dominio.

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.