这是一个老问题，我很惊讶没有人建议OP使用Apache Solr。

Apache Solr是一个全文搜索引擎，除了许多其他功能，还提供拼写检查或查询建议。从文档中可以看到:

默认情况下，Lucene拼写检查器首先根据 分由弦距计算和秒由频 (如有)在索引内的建议。

嗯…我认为谷歌使用他们庞大的数据语料库(互联网)来做一些严肃的NLP(自然语言处理)。

例如，他们拥有来自整个互联网的大量数据，以至于他们可以计算出三个单词序列出现的次数(称为三元组)。因此，如果他们看到一个句子:“pink frugr concert”，他们可以看到它的点击率很少，然后在语料库中找到最有可能的“pink * concert”。

他们显然只是做了Davide Gualano所说的一种变化，所以一定要阅读那个链接。谷歌当然使用它所知道的所有网页作为一个语料库，这使得它的算法特别有效。

几年前我在这方面看到过一些东西，所以可能已经改变了，但显然他们是通过分析相同用户在短时间内提交非常相似的查询的日志开始的，并根据用户如何纠正自己使用机器学习。

以下是直接来自来源的解释(几乎)

搜索101 !

在分钟 22：03

值得一看!

基本上，根据谷歌前CTO Douglas Merrill的说法，它是这样的:

1)你在谷歌里写了一个(拼错的)单词

2)你找不到你想要的(不要点击任何结果)

3)你意识到你拼错了这个词，所以你在搜索框里重写了这个词。

4)你找到你想要的(你点击第一个链接)

这个模式乘以数百万次，显示了什么是最常见的拼写错误，什么是最“常见”的更正。

这样谷歌几乎可以立即提供每种语言的拼写纠正。

这也意味着如果一夜之间每个人都开始把night拼成“nigth”，谷歌会建议用这个词来代替。

EDIT

道格拉斯将其描述为“统计机器学习”。

他们知道谁更正了查询，因为他们知道哪个查询来自哪个用户(使用cookie)

如果用户执行查询，只有10%的用户点击了结果，而90%的用户返回并输入了另一个查询(带有更正的单词)，这一次90%的用户点击了结果，那么他们知道他们已经找到了更正。

它们还可以知道这些是否是两个不同的“相关”查询，因为它们拥有它们所显示的所有链接的信息。

此外，他们现在将上下文纳入拼写检查，因此他们甚至可以根据上下文建议不同的单词。

请看谷歌wave (@ 44m06 s)的演示，它展示了如何考虑上下文来自动纠正拼写。

这里将解释自然语言处理是如何工作的。

最后，这里有一个很棒的演示，可以添加自动机器翻译(@ 1h 12m 47s)到混合。

我已经在视频中添加了分钟和秒的锚，可以直接跳到内容，如果它们不起作用，可以尝试重新加载页面或手动滚动到标记处。

通常，产品拼写纠正器会使用几种方法来提供拼写建议。一些人:

Decide on a way to determine whether spelling correction is required. These may include insufficient results, results which are not specific or accurate enough (according to some measure), etc. Then: Use a large body of text or a dictionary, where all, or most are known to be correctly spelled. These are easily found online, in places such as LingPipe. Then to determine the best suggestion you look for a word which is the closest match based on several measures. The most intuitive one is similar characters. What has been shown through research and experimentation is that two or three character sequence matches work better. (bigrams and trigrams). To further improve results, weigh a higher score upon a match at the beginning, or end of the word. For performance reasons, index all these words as trigrams or bigrams, so that when you are performing a lookup, you convert to n-gram, and lookup via hashtable or trie. Use heuristics related to potential keyboard mistakes based on character location. So that "hwllo" should be "hello" because 'w' is close to 'e'. Use a phonetic key (Soundex, Metaphone) to index the words and lookup possible corrections. In practice this normally returns worse results than using n-gram indexing, as described above. In each case you must select the best correction from a list. This may be a distance metric such as levenshtein, the keyboard metric, etc. For a multi-word phrase, only one word may be misspelled, in which case you can use the remaining words as context in determining a best match.

这是一个老问题，我很惊讶没有人建议OP使用Apache Solr。

Apache Solr是一个全文搜索引擎，除了许多其他功能，还提供拼写检查或查询建议。从文档中可以看到:

默认情况下，Lucene拼写检查器首先根据 分由弦距计算和秒由频 (如有)在索引内的建议。