我对检测类似文档的技术有着合理的理解包括首先计算他们的minhash签名(从他们的瓦片，或n-gram)，然后使用基于LSH的算法对它们进行有效聚类(即避免二次复杂度，这将导致天真的成对穷举搜索)。
我想做的是桥接三种不同的算法，我认为它们是所有这些都与这个minhash+LSH框架有关，但以不明显的方式：
(1) 在《海量数据集挖掘》一书(Rajaraman和Ullman)第3章第3.4.3节中概述的算法，似乎是minhashing 的规范描述
(2) Ryan Moulton的简单Simhashing文章
(3) Charikar所谓的SimHash算法，在本文中描述
我觉得这很困惑，因为我认为尽管(2)使用了这个术语"simhashing"，它实际上是以类似于(1)的方式进行minhashing，但一个集群只能由一个签名(甚至可能涉及复杂的多个散列函数)，而两个文档更有可能与(1)相似，因为签名可以在多个"带"中碰撞。(3) 在根据它们的汉明距离和LSH来比较签名这项技术意味着要对签名进行多重排序，而不是对它们进行分组。我还看到(在其他地方)最后一种技术可以包含加权，可用于更加强调某些文档部分，以及这在(1)和(2)中似乎缺乏。
最后，我提出两个问题：
(a) 有没有一种(令人满意的)方式来桥接这三种算法？
(b) 有没有办法把加权的概念从(3)引入(1)？
文章2实际上是在讨论minhash，但错误地将其称为simhash。这可能就是它现在被删除的原因(它在这里存档)。此外，令人困惑的是，它谈到了"串联"多个minhash，正如你正确观察到的那样，这减少了找到两个类似文档的机会。它似乎规定了一种只产生单一"波段"的方法，这将产生非常糟糕的结果。
算法是否可以桥接/组合
可能不会。要了解原因，您应该了解不同哈希的属性，以及如何使用它们来避免文档之间的n2比较。
minhash和simhash的属性：
本质上，minhash为每个文档生成多个散列，当有两个相似的文档时，这些散列的子集很可能是相同的Simhash为每个文档生成一个散列，如果有两个相似的文档，它们的Simhash很可能是相似的(具有较小的hamming距离)。
他们如何解决n2问题：
使用minhash，可以将所有哈希索引到包含它们的文档；因此，如果您为每个文档存储100个哈希，那么对于每个新传入的文档，您需要在索引中查找其100个哈希中的每一个，并找到所有共享至少(例如)50%哈希的文档。这可能意味着建立大量的临时统计，因为数十万个文档可以共享至少一个哈希。
有了simhash，有一种聪明的技术可以将每个文档的哈希以多个排列存储在多个排序的表中，这样就可以保证在这些表中的至少一个表中附近找到任何类似的哈希，直到某个hamming距离(3、4、5，根据哈希大小和表结构可能高达6或7)，只在低位不同。这使搜索类似文档变得高效，但限制您只能查找非常相似的文档。请参阅此simhash教程。
因为minhash和simhash的使用非常不同，所以我看不到桥接/组合它们的方法。理论上，你可以有一个生成1位哈希的minhash，并将它们连接成类似simhash的东西，但我认为这没有任何好处。
minhash中可以使用加权吗
是的。把minhashes想象成槽：如果每个文档存储100个minhashes，那么就可以填充100个槽。这些插槽不必全部由相同的文档功能选择来填充。您可以将一定数量的插槽用于仅根据特定功能计算的哈希(不过，应注意始终以在类似文档中选择相同功能的方式选择功能)。
因此，例如，如果您正在处理期刊文章，您可以为文档标题的minhashes分配一些槽，为文章摘要的minhashe分配一些槽以及为文档正文的minhash分配其余槽。您甚至可以留出一些单独的插槽来直接散列诸如作者姓氏之类的内容，而不必担心minhash算法。
它并不像simhash那样优雅，实际上你只是创建了所有单个特征哈希的逐位加权平均值，然后将每个位向上取整为1或向下取整为0。但它是相当可行的。