我热衷于尝试实施 minhashing 以查找接近重复的内容。 http://blog.cluster-text.com/tag/minhash/ 写得很好，但问题是您需要在文档中的带状疱疹上运行多少散列算法才能获得合理的结果。
上面的博文提到了 200 种散列算法。 http://blogs.msdn.com/b/spt/archive/2008/06/10/set-similarity-and-min-hash.aspx 将 100 列为默认值。
显然随着hash数量的增加，准确率也会提高，但是多少hash函数才是合理的呢？
引自博客
在我们的相似性估计中很难得到太多的误差线 小于 [7%]，因为统计上的误差条 采样值刻度——要将误差条减半，我们需要四个 数倍的样本。
这是否意味着将哈希数减少到 12 (200 / 4 / 4) 会导致 28% (7 * 2 * 2) 的错误率？
【问题讨论】：
生成 200 个散列值的一种方法是使用良好的散列算法生成一个散列值，并通过将良好的散列值与 199 组具有相同长度的随机位进行异或运算来廉价地生成 199 个值（即，如果您的良好哈希是 32 位，则构建一个包含 199 个 32 位伪随机整数的列表，并将每个良好的哈希与 199 个随机整数中的每一个进行异或）。
如果您使用无符号整数（有符号整数很好），不要简单地旋转位以廉价地生成哈希值 - 这通常会一遍又一遍地选择相同的瓦。将位向下循环一位与除以 2 并将旧的低位复制到新的高位位置相同。大约 50% 的好散列值的低位为 1，因此当低位旋转到高位位置时，它们将具有巨大的散列值，而不会祈祷成为最小散列。当您移动一位时，其他 50% 的良好哈希值将简单地等于它们的原始值除以 2。除以 2 不会改变哪个值最小。因此，如果具有良好散列函数的最小散列值恰好在低位中具有 0（50% 的可能性），那么当您移动一位时，它将再次给出最小散列值。举个极端的例子，如果来自良好散列函数的具有最小散列值的瓦的散列值恰好为 0，那么无论您旋转多少位，它都将始终具有最小散列值。有符号整数不会出现此问题，因为最小哈希值具有极端负值，因此它们往往在最高位有一个 1，后跟零（100...）。因此，只有最低位为 1 的哈希值在向下旋转一位后才有机会成为新的最低哈希值。如果具有最小哈希值的木瓦的最低位为 1，则在向下旋转一位后，它将看起来像 1100...，因此几乎可以肯定它会被具有类似 10 的值的不同木瓦击败...旋转后，避免了同一个木瓦以50%的概率连续两次被捡到的问题。
【讨论】：
差不多.. 但 28% 将是“错误估计”，这意味着报告的测量结果经常会不准确 +/- 28%。
这意味着报告的 78% 测量值很容易来自仅 50% 的相似性。 或者，50% 的相似性很容易被报告为 22%。对我来说，这对于业务预期来说听起来不够准确。
从数学上讲，如果您报告两位数，则第二个应该是有意义的。
为什么要将哈希函数的数量减少到 12 个？ “200 个哈希函数”的真正含义是，为每个 shingle/string 计算一次质量不错的哈希码 - 然后应用 200 个廉价且快速的转换，以强调某些因素/将某些位放在前面。
我建议将按位旋转（或洗牌）和XOR 操作结合起来。每个哈希函数可以组合旋转一定数量的位，然后通过随机生成的整数进行异或。
这既“传播”了 min() 函数在位周围的选择性，也“传播”了 min() 最终选择的值。
旋转的基本原理是“min(Int)”将在 256 次中的 255 次中仅选择 8 个最高有效位。只有当所有高位都相同时，低位才会在比较中产生任何影响。因此，扩展对于避免过度强调瓦中的一两个字符很有用。
XOR 的基本原理是，就其本身而言，按位旋转 (ROTR) 可以 50% 的时间（当从左侧移入 0 位时）收敛到零，这将导致“单独的”哈希函数显示出一种不希望的趋势，即一起向零重合 - 因此他们最终选择相同的瓦而不是独立的瓦的过度趋势。
有符号整数有一个非常有趣的“按位”怪癖，其中 MSB 为负数，但所有后续位均为正数，这使得 有符号整数的旋转收敛趋势不太明显 -- unsigned 是显而易见的。无论如何，在这些情况下仍必须使用 XOR。
Java 内置了 32 位哈希码。如果您使用 Google Guava 库，则可以使用 64 位哈希码。
感谢@BillDimm 的投入和坚持指出异或是必要的。
【讨论】：
您想要的可以从universal hashing轻松获得。像Corman et al 这样的流行教科书在第 11.3.3 pp 265-268 节中作为非常易读的信息。简而言之，您可以使用以下简单等式生成哈希函数族：
h(x,a,b) = ((ax+b) mod p) mod m
通过选择不同的 a 和 b 值，您可以生成许多相互独立的哈希码。
这个公式的优化版本可以在 C/C++/C#/Java 中实现如下：
(unsigned) (a*x+b) >> (w-M)
在这里， - w 是机器字的大小（通常为 32） - M 是您想要的哈希码的大小（以位为单位） - a 是适合机器字的任何奇数 - b 是任何小于 2^(w-M) 的整数
以上适用于对数字进行哈希处理。要对字符串进行哈希处理，请使用 GetHashCode 等内置函数获取哈希码，然后在上述公式中使用该值。
例如，假设您需要 200 个 16 位的字符串 s 哈希码，那么可以编写以下代码作为实现：
public int[] GetHashCodes(string s, int count, int seed = 0)
{
var hashCodes = new int[count];
var machineWordSize = sizeof(int);
var hashCodeSize = machineWordSize / 2;
var hashCodeSizeDiff = machineWordSize - hashCodeSize;
var hstart = s.GetHashCode();
var bmax = 1 << hashCodeSizeDiff;
var rnd = new Random(seed);
for(var i=0; i < count; i++)
{
hashCodes[i] = ((hstart * (i*2 + 1)) + rnd.Next(0, bmax)) >> hashCodeSizeDiff;
}
}
注意事项：
【讨论】：
只需使用 1 个哈希函数！（并保存 1/(f ε^2) 最小值。）
查看this article，了解最先进的实践和理论界限。它有这个漂亮的图表（下图），解释了为什么您可能只想使用一个 2 独立哈希函数并保存 k 最小值。
在估计集合大小时，论文表明您可以获得大约 ε = 1/sqrt(f k) 的相对误差，其中 f 是 jaccard 相似度，k 是保留值的数量。所以如果你想要错误ε，你需要k=1/(fε^2)，或者如果你的集合在1/3附近有相似性并且你想要10%相对错误，你应该保持300的最小值。
【讨论】：
似乎另一种获得 N 个好的散列值的方法是用 N 个不同的盐值对同一个散列进行加盐。
在实践中，如果第二次应用盐，您似乎可以散列数据，然后“克隆”散列器的内部状态，添加第一个盐并获得第一个值。您将此克隆重置为干净的克隆状态，添加第二个盐，并获得第二个值。冲洗并重复所有 N 项。
可能不如对 N 值的 XOR 便宜，但似乎有可能以最小的额外成本获得更高质量的结果，尤其是当被散列的数据远大于盐值时。
【讨论】：