对字符串列表进行近似搜索答案

【问题标题】：Approximate searching against a list of strings对字符串列表进行近似搜索
【发布时间】：2011-06-27 05:38:46
【问题描述】：

所以是的，我读到了如何在字符串之间使用编辑距离来决定两个字符串彼此之间的“接近”程度。该算法以动态问题的形式实现，需要 O(mn) 时间，其中 m 和 n 分别是文本和模式的长度。因此，如果我必须将一个字符串与 5000 个其他字符串进行匹配，这将花费大量时间，这在我的应用程序中是完全不能接受的。是否有更快的解决方案可以实施？我不介意用存储空间换取时间。

我在 Android 上看到了一个名为“Swype”的应用程序，它做了类似的事情。它根据自己的数据库搜索您的查询并建议结果。怎么会这么快？

注意：请不要推荐像 Lucene 这样的框架，因为我无法在 J2ME 上运行。

【问题讨论】：

这是为了打字更正吗？你确定你需要比 Levenshtein 距离更快的东西吗？ 5000 如果是字典中的短词，听起来还不错。
这基本上是为了根据预先填充的文章列表搜索文章名称（用户查询）。现在，由于用户可能输入了错误的查询，因此搜索必须建议最接近的匹配项，如果没有找到，则建议“不匹配”。

标签： java algorithm string java-me

【解决方案1】：

splix 的回答很好。作为另一种选择（对于非常大的字符串集），您可能需要考虑使用 n-gram 表示：

http://en.wikipedia.org/wiki/N-gram

这些用于许多数据库包中的近似模式匹配，因为它们使用传统的索引方法快速且易于实现。

【讨论】：

【解决方案2】：

我们用http://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_string_matching_algorithm 做几乎相同的事情，它对我们来说效果很好。

它的Java实现很少，你可以在网上找到它们

PS 你也可以查看其他的字符串匹配算法：http://en.wikipedia.org/wiki/String_searching_algorithm

【讨论】：

splix，“我们”是指 Swype 吗？
看起来 Aho 算法将许多关键字与文本匹配。就我而言，我有一个关键字可以对抗许多文本。那么这个过程会逆转吗？也就是我现在所有的文字都变成了关键词，单个的关键词变成了文字？
哎呀，我好像误解了你的问题:( 是的，这个算法只有在你有几千个模式来检查一个传入的文本时才有用。你可以按照你的建议反转它，但是我'不确定这是否是最佳选择。可能 n-gram 可以更好地帮助您

【解决方案3】：

这实际上取决于您要比较的文本。在下文中，我将介绍原始编辑距离框架内的两种加速方法。

我们曾经有过相同的任务，我们将一个短词序列（大约 10-30 个字符）与超过 30 万个短句（每个 10-30 个字符）的字典组合起来。在这种情况下，以下方法为我们节省了大量时间：

对目标字符串的字典进行排序（只需执行一次）
当您构建字符串 i 的 n*m 表时，您可以重用字符串 i-1 中的表，因为大多数行是共同的。

例如如果您有两个字符串"list of strings" 和下一个"list of words"，您可以重复使用表格的前 8 行，只需重新计算 5（两个字符串共有 8 个字符）。这样，我们只需对代码进行少量更改，即可节省高达 70-80% 的运行时间。

如果您的文本很少，第一种方法不会为您节省太多。但在这种情况下，您希望只有少数条目的编辑距离较小，而所有其他条目的编辑距离都很大。由于 n*m 表在每个方向上都是单调的（即每行的最小值以及每一列都是单调的），一旦达到预先指定的阈值，您就可以停止计算。如果您在初始阈值内没有找到解决方案，您甚至可以保存中间结果并“重新开始”计算（使用更高的界限）。

【讨论】：

这些是一些非常酷的优化，可以重用那里的表。我的数据集按字典顺序排序。但是我猜字符串（i-1）的表的重用很大程度上取决于数据集的类型。我不知道这对我有多大帮助。我打算将阈值保持在一个确定的值，通过测试各种值（即哪个值最适合我）我可能会更好地了解这个值。我会投票赞成你的答案，因为我真的很喜欢表格概念的重用。

【解决方案4】：

这也是你如何定义“关闭”的问题。如果您不坚持书面，但口头也可以，我可以建议soundex。它是一种非常快速的算法，可以查看 2 个单词是否拼音接近。

【讨论】：

我在上述算法的上下文中说“关闭”。 Soundex 听起来真的很酷。我去看看。