Differenze nella latenza di ricerca tra ricerca semantica AI e ricerca per parole chiave

Ci sono dati sulla latenza per la ricerca semantica e gli argomenti correlati semanticamente rispetto alla ricerca per parole chiave e agli argomenti suggeriti?

Grazie in anticipo.

Puoi spiegare meglio cosa intendi per latenza qui?

Per gli argomenti correlati, poiché ogni embedding è pre-calcolato, non ci sono costi aggiuntivi di runtime. Al contrario, la query SQL per trovare argomenti correlati è più veloce della nostra vecchia query per argomenti suggeriti, e memorizziamo nella cache gli argomenti correlati per prestazioni ancora migliori.

Per quanto riguarda la ricerca AI, il nostro attuale approccio HyDE[1] comporta una latenza significativa, motivo per cui avviene in modo asincrono e all’utente vengono presentati prima i risultati della ricerca standard con l’opzione di integrarli con i risultati AI quando questi sono pronti. Qui su Meta i risultati della ricerca AI sono pronti in media 4 secondi dopo i risultati della ricerca normale.


  1. GPT-4: HyDE sta per Hypothetical Document Embeddings, una tecnica utilizzata nella ricerca semantica per trovare documenti in base alle somiglianze nel loro contenuto. Questo approccio consente risultati di ricerca più precisi e contestualmente pertinenti valutando le somiglianze concettuali tra i documenti, piuttosto che basarsi esclusivamente sulla corrispondenza delle parole chiave. Rappresenta una tecnica di apprendimento zero-shot che combina le capacità di comprensione del linguaggio di GPT-3 con encoder di testo contrastivi, migliorando la capacità dell’AI di comprendere ed elaborare dati in linguaggio naturale in modo più sfumato ed efficace. ↩︎

3 Mi Piace

Esattamente quello che stavo cercando. Grazie Falco.

C’è stata qualche indagine riguardo ai modi per ridurre la latenza per la ricerca semantica?

La prima versione di AI Search aveva una latenza molto migliore, ma anche risultati molto peggiori.

Per quanto riguarda la prossima versione, abbiamo diversi piani per ridurre la latenza:

  • Utilizzare embedding a livello di post invece di embedding a livello di argomento

  • Utilizzare un modello di riordinamento per ordinare i risultati della ricerca

  • Rendere HyDE opzionale

Riteniamo che questo ci porterà a migliori risultati di ricerca e, nel processo, renderà anche la ricerca più veloce. E abbinato al nuovo hardware che offriamo senza costi aggiuntivi a tutti i nostri clienti ospitati, in grado di eseguire inferenze di embedding in soli 2 ms, stiamo appena iniziando a esplorare ciò che è possibile qui.

2 Mi Piace

Fantastico. Grazie per l’intuizione, Falco.

Un paio di altre domande, dato che stiamo valutando di attivare questa funzionalità per le nostre community.

  1. Sembra che, quando si attiva l’interruttore per mostrare i risultati della ricerca semantica, ciò che viene visualizzato all’utente è un mix di risultati dall’API di ricerca semantica e dall’API di ricerca per parole chiave. È corretto? In tal caso, come vengono classificati questi due set di risultati l’uno rispetto all’altro?
  2. In relazione a ciò, puoi commentare come funziona l’opzione “Ordina per:” con i risultati semantici. Noto, ad esempio, un articolo che ha l’icona a forma di stella accanto a sé in un ordinamento e poi non in un altro.



1 Mi Piace

Sì, esatto.

Utilizzando una tecnica chiamata “reciprocal rank fusion”. Potremmo passare a un re-ranker in futuro.

La ricerca semantica è incompatibile con le opzioni di ordinamento, poiché non abbiamo alcun calcolo di cutoff di distanza. Dovrebbe disabilitare/bloccare qualsiasi ordinamento temporale che non sia per pertinenza.

1 Mi Piace

Fantastico, grazie Falco. Da quello che abbiamo visto, l’API di ricerca semantica fornisce solo risultati di ricerca semantica al client. Quindi, presumibilmente la Reciprocal Rank Fusion avviene sul client. È corretto? Inoltre, avremmo la possibilità di sostituire noi stessi quell’algoritmo di riordino se volessimo sperimentare con opzioni diverse?

1 Mi Piace

Sì, esatto.

Tecnicamente, dato che è tutto basato sul client, potresti sovrascriverlo.

Detto questo, a lungo termine prevedo che faremo sempre più affidamento su modelli di riordino, che saranno tutti lato server per ovvie ragioni.

Capito. Grazie!

1 Mi Piace