「もしかして」のようなスペルチェッカーを書く
Webアプリケーションで検索クエリのスペルチェッカーを記述したいと思っています。Googleの「もしかして？」アルゴリズムは大まかにこれに基づいています： http://catalog.ldc.upenn.edu/LDC2006T1
つまり、修正候補を生成し、10億をはるかに超える5グラムを含む既知のnグラムの膨大なデータセット（Google Web 1T）に（検索クエリ内の隣接する単語とともに）出現する頻度でスコアを付けます。
私はWeb 1Tデータセットを使用していませんが、自分のドキュメントから約20万のドキュメントからn-gramセットを構築しています。数千または数億のn-gramが生成されると推定しています。
この種のプロセスは、基本的なコンピューティングパフォーマンスの理解の限界を押し上げています-アプリの起動時に、ハッシュテーブルまたは辞書のメモリにn-gramをロードするだけでいいですか？唯一の制限要因は、マシンのメモリ量ですか？
それとも私は間違った木を吠えていますか？おそらく、ある種のツリークエリ最適化を使用して、すべてのn-gramをグラフデータベースに配置しますか？それは十分に速いでしょうか？
それは最も単純で、うまくいくかもしれないので、私は最初にそれをメモリに実装します。しかし、そうはならないと思います。次に、使い慣れたオフラインシステム（データベース？）に移動して、速度が遅いことを確認します。シンプルなままで十分速いかもしれません。遅すぎると思います。
今、私たちは楽しい部分に来ます。これを読んだときに最初に思いついたのは「キャッシュ」です。運が良ければ、データベースへのアクセスの頻度が減るため、データベースの速度の問題を解決するのに十分な大きさのキャッシュを構築するのに十分なメモリが確保されます。
それがうまくいかない場合、次に私が試みることは、情報をできるだけ密に詰めて、より多くのメモリを取得しようとすることです。選択した言語がどのように情報を保存するかを学ぶため、これにはさらに手間がかかります。最終的に、n-gramを格納するために必要なスペースの量をより細かく制御できる言語に切り替えるか、必要なときにそれらを圧縮および解凍することができます。これはあなたをより良いプログラマーにするでしょうが、それはより長くかかります。
いつものように、あなた自身の道を見つけて、最初に最も簡単なことをしてください、そして実験して失敗することを恐れないでください。幸運を。