問題タブ [n-gram]

トライグラムを使用して文字列を近似的に照合するアプリケーションを作成しようとしています。これですべてのレコードがデータベースにあり、固定列のレコードを検索できるようにしたいと思います。検索したい値のハッシュバージョンを含む追加のフィールドを用意するのが最善ですか（そうであれば、それを保存するための最良の方法は何ですか？）、またはその場でトリグラムを生成する方が良いですか？

最近、私は、Cavnar と Trenkle の記事「N-Gram-Based Text Categorization」やその他の関連ソースに基づいて、テキストの分類と言語の分類をいじっています。

言語分類を行う場合、この方法は非常に信頼性が高く便利であることがわかりました。ドキュメントから最も一般的な n 個の N-gram を使用しているだけなので、N-gram 頻度プロファイルを生成するために使用されるドキュメントのサイズは、「十分な長さ」である限り、それほど重要ではありません。

一方、適切に機能するテキストの分類は私にはわかりません。IDF の重み付けや他の人々の実装などのさまざまな調整の有無にかかわらず、手元にあるアルゴリズムのさまざまなバリエーションの独自の実装の両方を試しました。カテゴリ参照ドキュメントに対してある程度類似したサイズの頻度プロファイルを生成できる限り、それは非常にうまく機能しますが、それらが少しだけ違い始めた瞬間、全体がバラバラになり、プロファイルが最も短いカテゴリが不均衡になりますそれに割り当てられたドキュメントの数。

さて、私の質問です。この影響を補償するための好ましい方法は何ですか? アルゴリズムは、カテゴリ頻度プロファイルの長さに等しい特定の N グラムの最大距離を想定しているため、明らかに発生していますが、何らかの理由で、それを修正する方法について頭を悩ませることはできません。私がこの修正に興味を持っている理由の 1 つは、実際には、長さが異なる可能性がある既知のカテゴリを持つドキュメントに基づいて、カテゴリ プロファイルの生成を自動化しようとしているからです (プロファイルが同じ長さであっても、最終的には長さが違う）。これに対する「ベストプラクティス」ソリューションはありますか?

私は現在、Solrのかなり単純な実装であると（誤って）考えていたものを使用していますNGramTokenizerFactoryが、管理アナライザーと実際のクエリ結果の間で一貫性のない奇妙な結果が得られており、いくつかのガイダンスを期待しています。

NGram（minGramSize = 2、maxGramSize = 2）インデックスに一致するユーザー入力を取得しようとしています。インデックス作成とクエリ時間のスキーマは次のとおりです。

1. を使用して、英数字以外のすべての文字を削除しPatternReplaceCharFilterます。
2. でトークン化しNGramTokenizerFactoryます。
3. 私は小文字を使用してLowerCaseFilterFactoryいます（これにより、文字以外のトークンがそのまま残るため、番号は残ります）。

以下のスキーマを使用すると、「PCB-1260」（適切にエスケープされたダッシュ付き）の検索は、「Arochlor-1260」のインデックス化されたトークン化された小文字の値と一致する必要があると思います（つまり、1260のバイグラムは「1226」です。インデックス値とクエリ値の両方で60"）。

残念ながら、ダッシュを削除しないと結果が得られません。[編集-ダッシュを適切にエスケープしてクエリに残しても、結果は得られません]。-を使用してすべての英数字を完全にパターン置換しているため、これは奇妙に思えPatternReplaceCharFilterます。これにより、すべての空白とダッシュが削除されると思います。

管理ページのクエリアナライザは、以下のスキーマを使用して適切な一致を示しています-そのため、私は少し途方に暮れています。私がここで見逃している 、PatternReplaceCharFilterまたはについての基本的な何かがありますか？NGramTokenizerFactory

コードや他の投稿を確認しましたが、これを理解できないようです。壁に頭をぶつけて1週間後、これをスタックの権限に提出します。

各行の複数の単語でパターン「マイニング」を実行しようとしています。Perl の Text::Ngrams モジュールを使用して N-gram 分析を行いました。これにより、各単語の頻度がわかります。しかし、私はこのテキストでパターンを見つけることについてかなり混乱しています.

tf-idf も頻度を見つけますが、これは私が行った Ngram 分析とどのように異なり、類似度の測定もどのように役立ちますか。

この概念の一部を理解できるようになる perl モジュールまたはコードのスニペットはありますか?

私は物理学のバックグラウンドを持っていますが、いくつかのパターン認識を行う必要があるため、これらのいくつかに少し慣れていないため、このトピックに関する良いリファレンスをいただければ幸いです。

入力テキストから n-gram 確率を自動的に生成し、1 つまたは複数の平滑化アルゴリズムも自動的に適用できる、ある種のパッケージまたはモジュール (できれば Python または Perl ですが、他のものも同様です) を見つけたいと思います。

つまり、NLTKNgramModelクラスのようなものを探しています。これは私の目的には使用できません。これは、平滑化関数にバグがあり、前に見たことのない単語の可能性を尋ねるとチョークするからです。

私は NLTK の開発フォーラムを読んだことがありますが、今のところ進展はないようです。

代替案はありますか？

テキストのブロックからキーフレーズを抽出する最良の方法は何ですか? 私はキーワード抽出を行うためのツールを書いています:このようなもの. Python と Perl で n-gram を抽出するためのライブラリをいくつか見つけましたが、Node でこれを書いているので、JavaScript ソリューションが必要です。既存の JavaScript ライブラリがない場合、誰かがこれを行う方法を説明してくれるので、自分で書くことができますか?

私は、大量の短いテキストをデータマイニングし、既存のカテゴリ名の大きなリストに基づいてこれらを分類するプロジェクトに取り組んできました。これを行うには、最初にデータから適切なテキスト コーパスを作成して、分類のための参照ドキュメントを作成し、次に分類の品質を許容レベルまで上げる方法を見つけなければなりませんでした。この部分は終了しました (幸いなことに、テキストの分類は、多くの人が多くの研究を行ってきたものです)。

次の問題は、さまざまなカテゴリを計算で相互にリンクする良い方法を見つけようとしているところです。つまり、「車」と「シボレー」が何らかの関連性があることをどのように認識するかを理解することです。これまでのところ、Cavnar や Trenkle などで説明されている N-Gram 分類方法を利用して、各カテゴリに対して作成したさまざまな参照ドキュメントを比較してみました。残念ながら、私がその方法から得た最高の結果は、カテゴリー間の約 50-55% の正しい関係であり、それらは最高の関係であり、全体的には約 30-35% であり、悲惨なほど低い.

他のアプローチもいくつか試しましたが、40% をはるかに超える関連リンクを取得できませんでした (関連性のない関係の例としては、カテゴリ「トラック」がカテゴリ「メイクアップ」に強く関連していることが挙げられます)。 」または「シボレー」に弱い（またはまったく関連しない）カテゴリ「おむつ」）。

今、私はこれを行うためのより良い方法を探してみましたが、何も見つからないようです (それでも、他の人が私よりもうまくやっていることがわかっています)。誰もこれについて経験がありますか？カテゴリ間の関係を作成するための使用可能な方法に関するヒントはありますか? 今のところ、私が試した方法では、十分なリレーションが得られないか、ジャンク リレーションの割合が高すぎます。

膨大な量のテキストをスキャンして単語の頻度を数えたいと思います（実際にはNLP / IRに精通している人にとってはn-gramの頻度です）。これにはJavaHashMapを使用します。つまり、テキストを1行ずつ処理します。行ごとに単語を抽出し、単語ごとにハッシュマップの対応する頻度を更新します。

問題は、このプロセスがどんどん遅くなることです。たとえば、約10万行/秒の処理から始まり、パフォーマンスはすぐに低下し始めます。約2800万行を超えると、パフォーマンスは1秒あたり16k行に低下し、もちろん低下し続けます。

最初に頭に浮かんだのは、ハッシュマップのエントリが多すぎることが原因で、すべてのプットとすべての取得が毎回遅くなることでした。したがって、私が試したのは、常に最も頻繁な（たとえば100k）エントリのみをハッシュマップに保持することでした。これは、頻度を単語にマップする2番目のマップを使用して行われました（ここのように：Javaの値マップによって自動的にソートされます）

これは一般的にはるかに高速に実行されました。（56 kライン/秒で開始しましたが、28 milラインに達するまでに、パフォーマンスは36.5kライン/秒にしか低下していませんでした）。しかし、これもはるかに遅い速度で下降し続けました-しかし、それが下降し続けたという事実は残っています。

ハッシュマップのサイズが同じままであるのに、なぜこれが発生するのかについて、考えられる説明はありますか？これはガベージコレクターと関係があると思いますか？つまり、私がハッシュマップとの間でオブジェクトを出し入れし続けるという事実は、メモリか何かを断片化しますか？それとも、ハッシュ関数の問題でしょうか？私は文字列を使用しているので、ハッシュ関数はJavaの文字列のデフォルトのハッシュ関数です。

前述のタスクを実行するコードの一部は次のとおりです。

http://pastebin.com/P8S6Sj86

注：私はJavaの初心者なので、回答を詳しく説明することは大歓迎です。

約 10,000 レコードを持つ MySQL データベースを構築しています。各レコードには、テキスト ドキュメント (ほとんどの場合、数ページのテキスト) が含まれます。データベース全体であらゆる種類の n-gram カウントを実行したいと考えています。多数のテキスト ファイルを含むディレクトリに対して必要なアルゴリズムを既に Python で記述していますが、そのためにはデータベースから 10,000 個のテキスト ファイルを抽出する必要があります。これにはパフォーマンスの問題があります。

私は MySQL の新人なので、n-gram 分析を行う組み込み機能があるかどうか、またはそれを行う優れたプラグインがあるかどうかはわかりません。私の分析では少なくとも 4 グラム (できれば 5 グラム) まで上げる必要があることに注意してください。また、n-gram カウントを行う前に、テキスト ドキュメントからストップワードを削除する機能も必要です。

コミュニティからのアイデアはありますか？

ありがとう、

ロン

コーパス内のn-gramを検索するためにNLTKを使用していますが、場合によっては非常に長い時間がかかります。n-gramの計算は、他のパッケージでは珍しい機能ではないことに気づきました（Haystackにはいくつかの機能があるようです）。これは、NLTKを放棄した場合に、コーパスでn-gramを見つけるための潜在的に高速な方法があることを意味しますか？もしそうなら、私は物事をスピードアップするために何を使うことができますか？