Hash 位置敏感哈希（LSH）是如何工作的？

我已经读过了，但不幸的是没有用

我不明白的是，一旦我们了解了将哪个bucket分配给我们的高维空间查询向量

q

：假设使用我们的一组对位置敏感的族函数

h_1，h_2，…，h_n

，我们将

q

转换为低维（

n

dimensions）散列码

c

然后

c

是分配给

q

的bucket的索引，其中（希望）也分配了它的最近邻，假设有100个向量

现在，为了找到

q

的NN，我们要做的是计算

q

和这100个向量之间的距离，对吗？所以

c

的使用只是为了索引（它只用于决定哪个bucket将

q

分配给`），对吗

---

另一种解决方案，如调查（第2.2节）所述，“哈希表查找”（之前描述的方法）的替代方案是“快速距离近似”，因此我们进行了详尽的研究，计算

c

和生成的哈希代码之间相对于数据集中每个元素的距离。这应该是快速的，因为散列码在低维空间中，距离的计算应该更快（例如，如果散列码空间是二进制的，那么我们可以使用XOR运算符快速计算两个散列码之间的汉明距离）

---

现在，我想知道的是：这两种方法的优点/缺点是什么？为什么我应该使用一种方法而不是另一种方法？

第一种描述的方法解释了近似最近邻搜索。是的，您只需检查bin

c

中的100个其他项，就可以获得最佳性能，但您在其他相邻的bucket中丢失优秀候选项的风险更高

lat/lon坐标的简单散列方案如下所示。通过查看同一Geohash块中的项目，您可以找到最近的商店，但网格边界附近可能会出现不准确的结果

---

可以找到一个快速距离近似的例子，它找到具有足够小的汉明距离（利用）的图像匹配。由于哈希值只有64位长，笔记本电脑GPU每秒可以进行7亿次比较。请注意，所有图像都已选中，未使用索引或哈希数据结构。通过这种方式，您可以保证获得所有匹配项（在相空间中）。

您是否有任何用于使用GPU处理64位向量的代码？在我使用的

asch:：device_vector

vectors中，asch是Nvidia的一个库。