1. 第一种是norvig介绍的方法，详细阐述了argmaxc P(c|w)的转换和求解办法。
这个概率不好直接算，但可以根据贝叶斯定理等价于argmaxc P(w|c)*P(c) / P(w)，因为是比较各个c之间的大小所以P(w)可以省略，最后就变成求argmaxc P(w|c)*P(c)就行了。P(c)可以看作是c在文本集合中出现的可能性；P(w|c)意味着本来心里想成是c结果打成了w的概率。
那就很好办了，P(c)可以从靠谱的语料中统计；P(w|c)可以用编辑距离来模拟关系，即编辑距离小的概率大。在实现上，对一个输入word，产生出有编辑距离1的字符串，就包括几种情况（“增删改换”）：删除一个字符、交换临近字符、把一个字符改成另一个、增加一个字符。这样产生的候选集会比较大，接近80%的纠错要求是满足了。如果在编辑距离1的基础上再产生编辑距离为2的更大的候选集，几乎就覆盖所有错别字了。
原文讲得比较精细，建模思路也很清晰，建议仔细阅读：https://norvig.com/spell-correct.html
2.第二种是lucene的spellchecker方法。
就是把编辑距离的临时产生到词典中检查，这种方案就是预先进行词典索引，当然是ngram的，对一个word任意2位或者3位字符进行索引，对用户输入的一个字符串，也同理按2或3位产生字符片段，利用OR的关系去检索，命中多的高分word最可能是拼写错误的。
当然因为是OR查询关系，所以会有很多也只“沾边”的词也被命中，所以最后除了考虑查询命中高分的，还要对命中的和输入的进行一步编辑距离阈值过滤。举个例子“word”，我们会有n2:wo/n2:or/n2:rd/n3:wor/n3:ord 这些碎片进行索引，当用户输入一个worg,会产生n2:wo/n2:or/n2:rg/n3:wor/n3:org，这些检索条件，会查到很多work, worth等等。
细节上可以有一些增强，比如单词两头的字符碎片权重更大等等。
参考：
https://www.quora.com/Can-ElasticSearch-be-used-to-check-the-spelling-of-the-query
https://blog.csdn.net/lgnlgn/article/details/8760785