0 
photos in washington VS show me photos in washington VS I wanna see all my photos in washington taken day before yesterday

what:photos
entities:washington (dont want to be too assuming)
when: 2013-03-14

プリセットクエリを条件に解析したい（上記のように）。私はこれらの資質が欲しい：

  1. 毛羽立ち（「見たい」）や小文字の名詞が存在する場合でも、関連する用語を抽出できます
  2. ウォーム プログラムは、HTTP 経由でリクエストを受け入れるか、ネットワーク通信を追加することができます
  3. ウォーム プログラムは 50 ミリ秒で応答し、妥当な文を保存するには最大で 500 MB のメモリが必要です。
  4. Python の経験が豊富で、Java の経験は少ない
  5. パーサーのデータ構造は扱いやすい

NLTK を使用していますが、遅いです。StanfordNLP と OpenNLP は実行可能な代替手段だと思いますが、プログラム開始の待ち時間が長すぎることがわかりました。代替手段がない場合は、サーブレットにそれらを統合してもかまいません。

4

1 に答える 1

0

Stanford Parser は堅実な選択肢であり、(研究コードが示すように) 十分にサポートされています。しかし、低遅延はあなたにとって重要な要件のように思えます。そのため、BUBS パーサー(完全な開示 - 私は BUBS に取り組んでいる主要な研究者の 1 人です) も検討することをお勧めします。

NLTK と直接比較したことはありませんが、Stanford Parser がパフォーマンスのニーズを満たしていないことに気付くかもしれません。この論文では、1 秒あたり約 60 ワード (約 2 ～ 3 文/秒) の合計スループットが見つかりました。これらのタイミングはかなり古いため、新しいハードウェアでは確実に改善されますが、おそらく 50 ミリ秒のレイテンシーには近づかないでしょう.

お気づきのように、起動時間はどのパーサーでも問題になります。高精度のモデルは必然的に非常に大きくなります。また、500 MB もおそらくかなりタイトです (私は通常、1 ～ 1.2 GB で BUBS を実行しています)。しかし、一度読み込まれると、BUBS のレイテンシは一般に 1 センテンスあたり 10 ミリ秒程度 (20 ～ 25 ワードのセンテンスの場合) であり、精度が低下し始める前に合計スループットを約 2500 ワード/秒まで押し上げることができます。これらの数値はパフォーマンスのニーズを満たす可能性があると思います。速度が近い高精度 (F1 >= 88-89) パーサーは他にありません。

注: 最も速い結果は、まだ Web サイトに投稿されていない最近の剪定モデルを使用した場合ですが、必要に応じてモデルを入手できます。ご不明な点がございましたら、お気軽にお問い合わせください。

于 2013-03-15T16:27:02.007 に答える