NLTK は確かに優れた学習プラットフォームですが、何百万もの顧客に確実にサービスを提供するようには設計されていません。
スケーラビリティの問題には、次の 2 つの方法で対処できます。
- 最初の「ビッグデータ」アプローチ: アルゴリズムを MapReduce に適合させ、MongoDB/Hadoop/Google MapReduce/ で実行します...そのようなソリューションをホストする場所はさまざまです (Amazon、Google、Rackspace など)。
- 2 番目の「独自のロール」アプローチ: 一般的なホスティング ソリューションまたは独自のデータセンターを使用します。
「ビッグデータ」アプローチ
これは、アルゴリズムを再考することを意味します。十分な数学的背景とアルゴリズムの十分な理解が必要です。実行時間は作業量とあまり関係がないため、アルゴリズムを置き換えることさえあるかもしれません。
したがって、あなたのアイデアを実装するという点では、あなたのスキルによっては、これが最も難しい (場合によっては不可能な) 解決策になるかもしれません。展開と将来の利益のために、これは最も簡単なソリューションです。
「ロール・ユア・オウン」アプローチ
スケーラビリティにはさまざまな意味があります。
- より大きなトレーニング セット
- より多くの顧客
- より多くのアルゴリズムとアプリケーション
- トレーニングセットを増やすことは、再トレーニングまたは適応のいずれかを意味する可能性があります
- ...
スケーラビリティに関しては、さまざまな桁があります。10 倍、100 倍、1000 倍、などとスケーリングしますか?
スケーラビリティの問題を克服するには、さまざまな方法があります。
- 並列化: サーバーの正確なコピーを追加し、負荷分散を行います
- パイプライン処理: 異なるサーバーで実行できる異なるステップでの分割処理
- より高価なハードウェア、より高速な CPU、RAM、ディスク、バス、ASIC、...
- クライアント側の処理
- リクエストのキャッシング
- ソフトウェアのパフォーマンス チューニング、C/C++ でのボトルネックの実装
- より良いアルゴリズムを使用する
- オフラインで行われること (例: cron ジョブ) と、リクエストごとに行われることのよりスマートな分離。
- ...
スケーラビリティのタイプが何であれ、それを克服するために使用する方法が何であれ、負荷テストを行って処理できることを確認してください。すべてのハードウェアをすぐに購入できるわけではないため、スケーリングされたインフラストラクチャの負荷テストを行うさまざまな方法があります。
- プロセッサ、メモリ、ディスク容量などを 1 時間あたりにレンタルします。これは、負荷テストを実行して救済するのに十分です。そうすれば、機器を購入する必要はありません。
- よりリスクが高い: 本番環境よりも少なくて安価な機器で負荷テストを行い、結果を推定します。アルゴリズムがどのようにスケールするかについての理論モデルがあるかもしれませんが、副作用には注意してください。プリンの証は食べ方にあります。
VC へのアプローチ (スケーラビリティに関する限り)
- アイデアを明確に説明するプロトタイプを作成します (必ずしもスケーラブルである必要はありません)。
- 将来のある時点で、どのくらいの費用がかかるか (最小/予想/最大の 1 回限り/継続的な費用) ですべてが問題ないことを自分自身に証明します。
- スケーラビリティが最初から問題にならないように、プライベート ベータ版から始めます。ベータ版を終了する期限はありません。見積もりはOKですが、締め切りはありません。そこは妥協しない!
幸運を!