開発中の Web アプリケーション (Pyramid で実行) にカスタム タガーを組み込みたいと考えています。ローカル マシンで NLTK を使用してタガーを正常に動作させていますが、本番環境では NLTK が比較的遅いことを読みました。
タガーの標準的な保存方法は、ピクルスにすることだそうです。私のマシンでは、11.7MB の pickle ファイルをロードするのに数秒かかります。
NLTK は本番環境でも実用的ですか? 私はscikit-learnまたは Mahout のようなものを見るべきですか?
NLTK が十分に優れている場合、メモリなどを適切に使用するための最善の方法は何ですか?
私はテキスト処理とそれに関連するNLP APIを実行し、Django アプリ (nginx の背後にある gunicorn) によって読み込まれる約 2 ダースの異なる pickled モデルを使用します。モデルは必要になるとすぐにロードされ、ロードされるとメモリに残ります。これは、gunicorn サーバーを再起動するたびに、モデルを必要とする最初のリクエストが読み込まれるまで数秒待たなければならないことを意味しますが、その後のすべてのリクエストでは、RAM に既にキャッシュされているモデルが使用されます。再起動は、通常はモデルの更新を伴う新しい機能を展開するときにのみ発生するため、いずれにせよそれらをリロードする必要があります。したがって、コードを頻繁に変更する予定がなく、リクエスト時間の一貫性に対する強い要件がない場合は、おそらく別のデーモンは必要ありません。
初期読み込み時間以外に、主な制限要因はメモリです。現在、ワーカー プロセスは 1 つしかありません。すべてのモデルがメモリに読み込まれると、1 つのプロセスが最大 1GB (YMMV、および 11MB のピクル ファイル 1 つに対しては、メモリ要件がはるかに低くなる) を使用する可能性があるためです。すでにロードされているモデルを使用して個々のリクエストを処理するのは十分に高速 (通常は 50 ミリ秒未満) であるため、現在、複数のワーカーは必要ありません。必要な場合、最も簡単な解決策は、より多くのワーカー プロセスを実行するのに十分な RAM を追加することです。
メモリが心配な場合は、scikit-learn を調べてください。同等のモデルは NLTK よりも大幅に少ないメモリを使用できるためです。ただし、必ずしも高速または正確であるとは限りません。
起動待ち時間を短縮する最善の方法は、Webアプリがテキストのスニペットをタグに送信するデーモン（永続サービス）としてタガーを実行することです。これにより、システムが起動したとき、およびデーモンを再起動する必要がある場合にのみ、タガーがロードされます。
NLTKがあなたのニーズに対して十分に速いかどうかを決めることができるのはあなただけです。タガーがロードされると、NLTKが知覚可能な遅延なしに数ページのテキストにタグを付けることができることにおそらく気づいたでしょう。しかし、リソースの消費と同時ユーザーの数は事態を複雑にする可能性があります。