wordpress做旅游网站,高德vr全景地图下载,西部网站建设,网站转换移动网站solr创建索引在上一篇文章中#xff0c;我谈到了Solr Spellchecker的工作原理#xff0c;然后向您展示了其性能的一些测试结果。 现在#xff0c;我们将看到另一种拼写检查方法。 与其他方法一样#xff0c;此方法使用两步过程。 相当快速的“候选单词”选择#xff0c;然… solr创建索引 在上一篇文章中我谈到了Solr Spellchecker的工作原理然后向您展示了其性能的一些测试结果。 现在我们将看到另一种拼写检查方法。 与其他方法一样此方法使用两步过程。 相当快速的“候选单词”选择然后对这些单词评分。 我们将从Solr使用的方法中选择不同的方法并测试其性能。 我们的主要目标是修正的有效性第二个方面是提高结果的速度。 考虑到我们正在获得结果的正确性我们可以忍受稍慢的性能。 我们的策略是使用特殊的Lucene索引并使用模糊查询对其进行查询以获取候选列表。 然后我们将使用Python脚本对候选人进行排名如果获得更好的结果可以轻松地在Solr拼写检查器子类中对其进行转换。 候选人选择 历史上模糊查询一直被认为是性能较慢的查询但是由于在1.4版本中已对其进行了优化因此对于我们算法的第一部分来说它们是一个不错的选择。 因此这个想法将非常简单我们将构建一个Lucene索引其中每个文档都是一个字典单词。 当我们必须纠正一个拼写错误的单词时我们将对该单词进行简单的模糊查询并获得结果列表。 结果将是与我们提供的单词相似的单词即编辑距离较小。 我发现大约有70名候选人可以使我们获得出色的成绩。 对于模糊查询我们涵盖了所有的错字因为正如我在上一篇文章中所说大多数错字相对于正确的单词的编辑距离均为1。 但是尽管这是人们在键入时最常见的错误但还有其他类型的错误。 我们可以找到三种拼写错误[Kukich] 印刷错误 认知错误 语音错误 当人们知道正确的拼写但在打字时却使运动协调失误时就会出现打字错误。 认知错误是由于人的知识不足引起的。 最后语音错误是认知错误的一种特殊情况认知错误是指听起来正确但拼写错误的单词。 我们已经用模糊查询解决了印刷错误但是我们也可以为语音错误做些事情。 Solr的分析包中有一个语音过滤器其中除其他外还具有双重语音识别算法。 以相同的方式执行模糊查询以查找相似的单词我们可以为该单词的等效语音索引并对其执行模糊查询。 我们必须手动获取该单词的等效词因为Lucene查询解析器不会分析模糊查询并使用该单词构造一个模糊查询。 简而言之对于候选选择我们使用以下solr模式构建索引 fieldType namespellcheck_text classsolr.TextField positionIncrementGap100 autoGeneratePhraseQueriestrueanalyzer typeindextokenizer classsolr.KeywordTokenizerFactory/filter classsolr.LowerCaseFilterFactory/filter classsolr.PhoneticFilterFactory encoderDoubleMetaphone maxCodeLength20 injectfalse//analyzer/fieldTypefield nameoriginal_word typestring indexedtrue storedtrue multiValuedfalse/field nameanalyzed_word typespellcheck_text indexedtrue storedtrue multiValuedfalse/field namefreq typetfloat storedtrue multiValuedfalse/ 如您所见analyzered_word字段包含单词的“音似”。 频率字段将在算法的下一阶段中使用。 它只是该术语在语言中的出现频率。 我们如何估计语言中一个单词的出现频率 计算大文本语料库中单词的出现频率。 在这种情况下术语的来源是维基百科我们使用Solr的TermComponents来计算每个术语在维基百科中出现的次数。 但是维基百科是由会出错的普通人编写的 我们如何才能将其视为“正确的字典” 我们利用撰写维基百科的人们的“集体知识”。 这个从维基百科提取的术语词典有很多术语 超过1.800.00其中大多数甚至都不是单词。 维基百科中可能正确拼写了高频单词。 从大量的单词集构建字典并考虑最正确的单词的这种方法并不新鲜。 在[Cucerzan]中他们使用相同的概念但使用查询日志来构建字典。 可以看出Google的“您的意思是”使用了类似的概念 。 我们可以在这里添加一些优化。 我发现我们可以删除一些单词并获得良好的结果。 例如我删除了频率为1的单词和以数字开头的单词。 我们可以根据其他条件继续删除单词但是我们将这样保留。 因此建立索引的过程很简单我们通过Solr的TermsComponent从Wikipedia索引中提取所有术语以及频率然后使用SolrJ在Solr中创建索引。 候选人排名 现在的候选人排名。 对于算法的第二阶段我们将利用信息论尤其是噪声信道模型 。 应用于这种情况的嘈杂通道假定人类知道一个单词的正确拼写但是通道中的一些噪声引入了错误结果我们得到了另一个拼写错误的单词。 我们直观地知道在尝试键入“ house”时我们不太可能获得“ sarasa”因此嘈杂的渠道模型引入了某种形式来确定错误的可能性。 例如我们拼错了“ houze”我们想知道哪一个是我们最想输入的单词。 为实现这一点我们拥有大量可能的单词词典但并非所有单词都具有相同的可能性。 我们希望获得打算输入的可能性最高的单词。 在数学中称为条件概率 假设我们键入“ houze”那么每个正确单词成为我们想要的单词的可能性有多高。 条件概率的表示法是Phouse|houze表示给定“ houze”时“ house”的概率 这个问题可以从两个角度看待我们可能认为最常见的词更有可能例如“ house”比“ hose”更有可能因为前者是一个更常见的词。 另一方面我们也凭直觉认为“房屋”比“光合作用”更有可能因为两个词的差异很大。 这两个方面均由贝叶斯定理正式推论 我们必须最大化这种可能性并且只有一个参数正确的候选单词在所示情况下为“ house”。 因此拼写错误的单词的概率将是恒定的我们对此不感兴趣。 公式简化为 为了给它增加更多的结构科学家给这两个因素起了名字。 Phouze|house因子是错误模型或通道模型并且与通道在尝试写入第二个单词时引入此特定拼写错误的可能性有关。 第二个术语Phouse称为语言模型它使我们了解单词在语言中的普遍程度。 到目前为止我仅介绍了该模型的数学方面。 现在我们必须提出这两个概率的具体模型。 对于语言模型我们可以在文本语料库中使用术语的频率。 从经验上我发现使用频率的对数比单独使用频率要好得多。 也许是因为我们要减少频繁项的权重而不是减少频繁项的权重而对数正是这样做的。 不仅存在一种构造渠道模型的方法。 已经提出了许多不同的想法。 我们将使用一个基于Damerau-Levenshtein距离的简单距离。 但是我也发现第一阶段的模糊查询在找到候选者方面做得很好。 在某些数据集的一半以上的测试用例中它首先给出了正确的单词。 因此通道模型将是Damerau-Levenshtein距离和Lucene为模糊查询条件创建的得分的组合。 排名公式为 我编写了一个小脚本python该脚本执行了之前所说的所有操作 from urllib import urlopen
import doubleMethaphone
import levenshtain
import jsonserver http://benchmarks:8983/solr/testSpellMeta/def spellWord(word, candidateNum 70):#fuzzy soundlikemetaphone doubleMethaphone.dm(word)query original_word:%s~ OR analyzed_word:%s~ % (word, metaphone[0])if metaphone[1] ! None:query query OR analyzed_word:%s~ % metaphone[1]doc urlopen(server select?rows%dwtjsonfl*,scoreomitHeadertrueq%s % (candidateNum, query)).read( )response json.loads(doc)suggestions response[response][docs]if len(suggestions) 0:#scorescores [(sug[original_word], scoreWord(sug, word)) for sug in suggestions]scores.sort(keylambda candidate: candidate[1])return scoreselse:return []def scoreWord(suggestion, misspelled):distance float(levenshtain.dameraulevenshtein(suggestion[original_word], misspelled))if distance 0:distance 1000fuzzy suggestion[score]logFreq suggestion[freq]return distance/(fuzzy*logFreq) 在前面的清单中我必须做一些说明。 在第2行和第3行中我们使用Levenshtein距离和变音位算法的第三方库。 在第8行中我们正在收集70个候选人的列表。 该特定数字是凭经验找到的。 候选数越高算法就越慢而算法越少则效果越差。 我们还将第30行的候选单词中的拼写错误的单词排除在外。由于我们使用Wikipedia作为来源因此通常会在字典中找到拼写错误的单词。 因此如果Leveshtain距离为0相同的单词我们将其距离加1000。 测验 我使用此算法进行了一些测试。 第一个将使用Peter Norvig在他的文章中使用的数据集。 我在大约80的情况下都在第一个位置找到了该单词的正确建议 那是一个非常好的结果。 具有相同数据集但算法和训练集不同的Norvig获得了67 现在让我们重复上一篇文章的一些测试以查看改进。 在下表中我向您显示结果。 测试集 Solr 新 Solr时间[秒] 新时间[秒] 改善 时间损失 FAWTHROP1DAT.643 45,61 81,91 31,50 74,19 79,58 135,55 batch0.tab 28,70 56,34 21,95 47,05 96,30 114,34 SHEFFIELDDAT.643 60,42 86,24 19,29 35,12 42,75 82,06 我们可以看到我们在改正效果方面得到了很好的改进但是大约需要两倍的时间。 未来的工作 我们如何改进此拼写检查器。 好了研究候选人名单后可以发现其中通常包含正确单词95的次数。 因此我们所有的努力都应旨在改进评分算法。 我们有许多改进渠道模型的方法 几篇论文表明根据语言统计数据计算更复杂的距离对不同的字母转换加权可以为我们提供更好的度量。 例如我们知道写“ houpe”比写“ houze”的可能性要小。 对于语言模型可以通过向单词添加更多上下文来获得重大改进。 例如如果我们拼错了“ nouse”很难说出正确的单词是“ house”或“ mouse”。 但是如果我们添加更多的单词“画我的鼻子”则很明显我们所寻找的单词是“房子”除非您有与啮齿动物有关的奇怪习惯。 这些也称为ngram在这种情况下是单词而不是字母。 Google提供了大量ngram可以下载它们的频率。 最后但并非最不重要的一点是可以通过用Java编写脚本来提高性能。 该算法的一部分在python中。 再见 作为对所有感兴趣的人的更新Robert Muir在“ Solr用户”列表中告诉我 有一个新的拼写检查器DirectSpellChecker它当时在后备箱中现在应该是Solr 3.1的一部分。 它使用与本条目中介绍的技术类似的技术而不会降低性能。 参考资料 [Kukich] Karen Kukich –自动校正文本中的单词的技术– ACM计算调查–第24卷第4期1992年12月 [Cucerzan] S. Cucerzan和E. Brill拼写校正是一个利用Web用户集体知识的迭代过程。 2004年7月 Peter Norvig –如何编写拼写校正器 参考 emmaespina博客上的JCG合作伙伴 Emmanuel Espina 用Solr创建了拼写检查 工具 。 翻译自: https://www.javacodegeeks.com/2012/06/solr-creating-spellchecker.htmlsolr创建索引
