适用于非常小的集群的聚类算法

Posted 2023-03-12

【中文标题】适用于非常小的集群的聚类算法

【英文标题】：Clustering algorithm appropriate for very small clusters

【发布时间】：2012-11-14 00:50:41

【问题描述】：

我正在尝试在大约 5000 条记录的列表中查找重复项。每条记录都是一个人的姓名和地址，但都在一个字段中输入不一致，所以我正在尝试一种模糊匹配方法。我的方法（使用 rapidminer）是对文本进行一些预处理（即标记化，删除常见和不相关的词，例如“先生”等），生成 TF-IDF 并使用 DBSCAN 对匹配记录进行聚类。这很有效，并且给出了很好的结果，但是当我尝试运行完整的数据集时需要很长时间。也会导致很多簇只有一个元素，不知道这对DBSCAN的计算时间有什么影响。

是否有一种聚类算法可以更快地处理此类数据，或者是否有更好的方法来解决这个问题？

【问题讨论】：

您尝试过/您可以尝试更激进的预处理吗？比如：如果一个名字是唯一的，它可以立即被挑出来，等等。

也许 k-means 会是一个不错的选择。它的执行速度应该很快。

@Zhenya: 不是真的，挑名字不容易。即使阅读它们，也并不总是清楚哪些词是，例如人名或街道名称。

@KarelBurda：是的，它很快，但它需要集群的数量，我不知道。

好吧，然后我会尝试挑选出那些只有唯一单词的记录。 IE。 “John Smith ***lyn”和“Tokyo Jim Jones”绝对应该属于不同的类别。

【参考方案1】：

您确定 聚类 是最好的方法吗？

对我来说，这听起来好像您正在执行近重复检测，即您定义了一些阈值，只是想查找在此相似性阈值内是否有任何其他对象。 如果您使用的 DBSCAN 具有较低的 minPts 值（例如，minPts=2），那么您实际上并不是在使用 DBSCAN。

如果 DBSCAN 生成单元素集群，则它的实现不正确。 DBSCAN 中不能有单元素簇；这些是噪声对象，应该这样对待。

我不知道 RapidMiner 中 DBSCAN 的质量。 如果它是基于 Weka 代码的，那就是垃圾（即，甚至不用费心去尝试 Weka！）。而且真的很慢。至少拼写错误：DBScan不正确，是缩写，应该拼写DBSCAN...

天真地实现 DBSCAN 的复杂性O(n^2)。如果你有一个好的索引来支持查询，它可以在O(n log n) 中运行。如果你有一个非常糟糕的实现，它可能会因为数据结构效率低下而下降到O(n^3)...（通过快速检查，rapidminer 应该在O(n^2)，但由于使用LinkedList<Integer>，垃圾收集器可能会花费不少）

5000 个对象实际上并没有那么多。所以很可能问题不在于聚类算法的复杂性（我使用 ELKI 在单个 CPU 上在 60 秒内对 100000 个对象运行了 DBSCAN），而在于距离计算。快速浏览一下 rapidminer，我看不出它是否支持稀疏向量、稀疏向量上的有效余弦相似度，甚至没有预计算向量长度以充分利用向量稀疏性的技巧（以预处理每个对象和存储为代价）一个额外的双）。现在很明显，如果您的向量与文本向量一样具有 1% 的稀疏度，那么使用低效的非稀疏距离计算将花费大约 100 倍的时间，计算大量的 0。

我刚刚在一个类似文本的数据集上运行了带有 ELKI 的 DBSCAN。它没有你的那么大：只有 3333 个观测值和 50 个维度，以及 13% 的稀疏性）。运行 DBSCAN 需要 7 秒，epsilon=0.001，minpts=3，余弦相似度；未启用索引加速。所以很明显，问题似乎不在于 DBSCAN，而在于 RapidMiner 实现。请注意，ELKI 与稀疏数据一起使用有点棘手。您需要以正确的输入格式输入数据，正确设置多个过滤器等 - 我现在不向初学者推荐它。这更要强调它可能是 RapidMiner 的相似函数实现杀死了你的运行时。

我不想阻止您使用 DBSCAN。从聚类的角度来看，它是你能找到的最合适的算法之一：它支持任意距离函数（k-means 不支持），你不需要事先知道聚类的数量（显然你不需要't) 并且它还会选择不对所有内容进行聚类（显然你有很多非聚类对象）。

但是，我相信您确实不想要集群。您似乎对重复检测感兴趣，我假设您通过例如获得更好的性能和结果质量。将您的文档加载到文本搜索引擎（如 Lucene 或 Xapian）中，然后查询专用文本搜索引擎以查看您是否有近乎重复的内容。 而这些文本搜索引擎真的很擅长：匹配文本。我认为比 rapidminer 好得多。

【讨论】：

感谢您提供信息丰富的回复！让它运行 10 小时后，我认为 Rapidminer 的实现肯定存在问题。我不确定集群是否是正确的方法，因此我将研究您建议的其他选项。

我尝试在 reuters 数据集上运行 ELKI，但它现在也已经运行了几个小时，完成度为 3%。维数当然有很大的影响。它强调了为了检测相似的文本文档，我们需要使用一些索引。我认为 Lucene 或 Xapian 可能是不错的选择。

【参考方案2】：

您的问题不是集群，而是approximate string matching。

您可能需要查看 Levenshtein Edit Distances 或使用several existing 选项之一。