Ближайший сосед — недостаток хеширования с учетом местоположения

Хеширование с учетом местоположения кажется отличным методом для KNN без каких-либо недостатков. Однако в чем недостаток хеширования с учетом местоположения, если кто-то использует его в промышленности для практических приложений? В каких ситуациях LSH потерпит неудачу или будет работать плохо? Или кодирование/настройка занимает много времени?


nearest-neighbor locality-sensitive-hash
person jonty rhodes    schedule 10.12.2015    source источник
comment
Не уверен, что это подходящий форум для обсуждения. stackoverflow предназначен для ответов на конкретные технические вопросы.   -  person    schedule 10.12.2015
comment
есть хорошая бумага?   -  person user3085931    schedule 10.12.2015
comment
@jonty Rhodes, я ответил на твой вопрос!   -  person gsamaras    schedule 10.05.2016

Ответы (1)


arrow_upward
2
arrow_downward

Это довольно широкий вопрос, но, поскольку вы здесь впервые, я попытаюсь ответить.

LSH не так совершенен, как вы описываете, конечно, поищите статьи об этом, пожалуйста. Может быть, этот вопрос может помочь: Как понять хеширование с учетом местоположения?

Существует множество библиотек LSH, обеспечивающих автоматическую настройку параметров, но не самая важная из них, R, используемая при решении рандомизированной версии R-ближнего соседа. Это серьезный недостаток, поскольку пользователю приходится вручную определять R при каждом вводе. Это, на мой взгляд, очень важный аспект, который вы должны учитывать, когда дело доходит до практических приложений.

Что касается производительности, все зависит от вашего вклада! Например, в моем проекте kd-GeRaF я тщательно протестировал LSH и видел, что у него могут быть некоторые важные проблемы, когда речь идет о точности и скорости поиска. Объем наборов данных находился в многомерном пространстве, где выполнялась ANNS.

person gsamaras    schedule 11.12.2015