问题标签 [n-gram]

我正在尝试创建一个使用三元组进行近似字符串匹配的应用程序。现在所有记录都在数据库中，我希望能够搜索固定列上的记录。最好有一个附加字段，其中包含我要搜索的值的散列版本（如果是，存储它的最佳方法是什么？）还是动态生成三元组更好？

最近我一直在研究基于 Cavnar 和 Trenkle 的文章“基于 N-Gram 的文本分类”以及其他相关资源的文本分类和语言分类。

对于进行语言分类，我发现这种方法非常可靠和有用。用于生成 N-gram 频率分布的文档的大小并不重要，只要它们“足够长”，因为我只是使用文档中最常见的 n N-gram。

另一方面，运作良好的文本分类让我望而却步。我已经尝试了我自己对手头算法的各种变体的实现，有和没有各种调整，例如 idf 加权和其他人的实现。只要我可以为类别参考文档生成大小相似的频率配置文件，它就可以很好地工作，但是当它们开始差异太大时，整个事情就会崩溃，并且配置文件最短的类别最终会变得不成比例分配给它的文档数量。

现在，我的问题是。补偿这种影响的首选方法是什么？这显然正在发生，因为该算法假定任何给定 N-gram 的最大距离等于类别频率分布的长度，但由于某种原因，我无法解决如何修复它。我对此修复感兴趣的一个原因实际上是因为我正在尝试根据具有已知类别的文档自动生成类别配置文件，该文档的长度可能会有所不同（即使它们的长度相同，配置文件也可能最终成为不同的长度）。对此有“最佳实践”解决方案吗？

我目前正在使用我（错误地）认为是 Solr 的一个相当简单的实现NGramTokenizerFactory，但是我得到了奇怪的结果，这些结果在管理分析器和实际查询结果之间不一致，我希望得到一些指导。

我试图让用户输入匹配我的 NGram (minGramSize=2, maxGramSize=2) 索引。我的索引和查询时间架构如下，其中

1. 我使用删除所有非字母数字字符PatternReplaceCharFilter。
2. 我用 标记化NGramTokenizerFactory。
3. 我使用小写LowerCaseFilterFactory（保留非字母标记，所以我的数字将保留）。

使用下面的模式，我认为搜索“PCB-1260”（带有正确转义的破折号）应该匹配“Arochlor-1260”的索引 Ngram 标记和小写值（即 1260 的双元组是“12 26索引值和查询值均为 60"）。

不幸的是，除非我删除破折号，否则我没有得到任何结果。[编辑-即使我正确地转义破折号并将其留在查询中，我也没有得到任何结果]。这看起来很奇怪，因为我正在使用PatternReplaceCharFilter- 我假设删除所有空格和破折号来对所有字母数字字符进行完整的模式替换。

管理页面中的查询分析器使用下面的模式显示了正确的匹配 - 所以我有点茫然。我在这里遗漏了 关于 thePatternReplaceCharFilter或 the 的一些基本内容吗？NGramTokenizerFactory

我已经检查了代码和其他帖子，但似乎无法弄清楚这一点。在将我的头撞到墙上一周之后，我将这个提交给堆栈的权威......

我正在尝试在每行的多个单词中进行一些模式“挖掘”。我已经使用 perl 中的 Text::Ngrams 模块完成了 N-gram 分析，它给出了每个单词的频率。然而，我对本文中的发现模式感到非常困惑。

我认为 tf-idf 也发现了频率，但这与我所做的 Ngram 分析有什么不同，以及相似性测量也有什么帮助。

请问是否有任何 perl 模块或代码片段可以让我理解其中的一些概念。

请我来自物理背景，但必须做一些模式识别，所以我对其中一些有点陌生，对此主题的良好参考将不胜感激。

我想找到某种类型的包或模块（最好是 Python 或 Perl，但其他人会这样做），它可以从输入文本自动生成 n-gram 概率，并且也可以自动应用一个或多个平滑算法。

也就是说，我正在寻找类似 NLTKNgramModel类的东西。我不能将其用于我的目的，因为平滑函数存在一些错误，当您询问它以前未见过的单词的概率时，这会使它窒息。

我已经阅读了 NLTK 的开发论坛，到目前为止，这方面似乎没有任何进展。

有什么替代品吗？

从文本块中提取关键短语的最佳方法是什么？我正在编写一个工具来进行关键字提取：类似这样的东西。我找到了一些 Python 和 Perl 库来提取 n-gram，但我是在 Node 中编写的，所以我需要一个 JavaScript 解决方案。如果没有任何现有的 JavaScript 库，有人可以解释如何做到这一点，以便我自己编写吗？

I've been working on a project to data-mine a large amount of short texts and categorize these based on a pre-existing large list of category names. To do this I had to figure out how to first create a good text corpus from the data in order to have reference documents for the categorization and then to get the quality of the categorization up to an acceptable level. This part I am finished with (luckily categorizing text is something that a lot of people have done a lot of research into).

Now my next problem, I'm trying to figure out a good way of linking the various categories to each other computationally. That is to say, to figure out how to recognize that "cars" and "chevrolet" are related in some way. So far I've tried utilizing the N-Gram categorization methods described by, among others, Cavnar and Trenkle for comparing the various reference documents I've created for each category. Unfortunately it seems the best I've been able to get out of that method is approximately 50-55% correct relations between categories, and those are the best relations, overall it's around 30-35% which is miserably low.

I've tried a couple of other approaches as well but I've been unable to get much higher than 40% relevant links (an example of a non-relevant relation would be the category "trucks" being strongly related to the category "makeup" or the category "diapers" while weakly (or not at all) related to "chevy").

Now, I've tried looking for better methods for doing this but it just seems like I can't find any (yet I know others have done better than I have). Does anyone have any experience with this? Any tips on usable methods for creating relations between categories? Right now the methods I've tried either don't give enough relations at all or contain way too high a percentage of junk relations.

我想扫描大量文本并计算词频（n-gram 频率实际上适用于那些熟悉 NLP/IR 的人）。我为此使用了 Java HashMap。所以会发生什么是我逐行处理文本。对于每一行，我提取单词，对于每个单词，我更新哈希图中的相应频率。

问题是这个过程变得越来越慢。例如，它首先处理大约 100k 行/秒 - 性能立即开始下降。在大约 2800 万行之后，性能已经下降到 16k 行/秒——当然还在不断下降。

首先想到的是，这是由于 hashmap 中的条目过多造成的，这导致每次 put 和 get 每次都变慢。所以我尝试的是在任何时候只在哈希图中保留最频繁的条目（比如 100k）。这是通过使用将频率映射到单词的第二个映射来完成的（如这里：Automatically sorted by values map in Java）

一般来说，这执行得更快。（虽然开始时为 56,000 行/秒，但当达到 2800 万行时，性能仅下降到 36.5k 行/秒）。然而，这也一直在以更慢的速度下降——但事实仍然是，它一直在下降。

当哈希图的大小保持不变时，您是否有任何可能的解释为什么会发生这种情况？您认为这与垃圾收集器有关吗？意思是，我不断向/从哈希映射中放置和删除对象的事实会碎片化内存或其他东西？还是可能是散列函数问题？由于我使用的是字符串，因此散列函数是 Java 对字符串的默认散列函数。

这是执行上述任务的代码部分：

http://pastebin.com/P8S6Sj86

注意：我是一名 Java 新手，因此您的答案中的任何详细说明都非常受欢迎

我正在构建一个包含大约 10,000 条记录的 MySQL 数据库。每条记录将包含一个文本文档（大多数情况下是几页文本）。我想在整个数据库中进行各种 n-gram 计数。我已经用 Python 编写了算法，可以针对包含大量文本文件的目录执行我想要的操作，但要做到这一点，我需要从数据库中提取 10,000 个文本文件——这会产生性能问题。

我是 MySQL 的新手，所以我不确定它是否有任何内置功能可以进行 n-gram 分析，或者是否有好的插件可以做到这一点。请注意，在我的分析中，我需要达到至少 4 克（最好是 5 克），所以我见过的简单的 2 克插件在这里不起作用。在进行 n-gram 计数之前，我还需要能够从文本文档中删除停用词。

来自社区的任何想法？

谢谢，

罗恩

我正在使用 NLTK 在语料库中搜索 n-gram，但在某些情况下需要很长时间。我注意到计算 n-gram 在其他包中并不少见（显然 Haystack 有一些功能）。这是否意味着如果我放弃 NLTK，在我的语料库中找到 n-gram 的方法可能更快？如果是这样，我可以用什么来加快速度？