5

従来とは異なる種類のテキスト検索用のテキスト検索エンジンを探しています。どのツール (Lucene、Sphinx、Xapian、またはその他のもの) が自分に最も適しているかについてのアドバイスと、どこから始めればよいかについての指針が必要です。

私はグラフ（原子と結合）として表現された分子を持っています。サイズ k までのすべてのサブグラフを列挙する方法があります。技術的には、入力はSMILESで、出力は正規の SMARTS と各サブグラフ/SMARTS の発生回数です。

たとえば、入力分子が「CCO」の場合、標準的な結果は {"C": 2, "O": 1, "CC": 1, "OC": 1, "CCO": 1} であり、分子が " SCO " の場合、標準的な結果は {"C": 1, "S": 1, "O": 1, "CS": 1, "OC": 1, "SCO": 1} です。これらは小さな例です。実際の分子については、「CC(C)O」、「CCCOCC」、「cn」、「cccc(c)O」のような約 500 の「単語」を取得しました。

分子を特徴的な文字列とカウントのコレクションとして見ることは、テキスト検索ツールを使用してテキスト レベルで比較を行うことができることを意味し、それらが化学レベルで意味を持つことを期待しています。

たとえば、おそらくtf-idf重みでコサイン類似度を使用し、類似のサブパターンを探すことで類似の分子を見つけることができます。上記の「CCO」と「SCO」の例では、コサイン類似度は (2*1+1*1+1*1)/sqrt(2*2+1*1+1*1+1*1+1* 1)/sqrt(6*(1*1)) = 4/sqrt(8*6) = 0.58.

別の例として、「CCS」部分構造を含む分子を見つけたい場合、カウントに基づいて高速逆インデックス検索を実行できます (分子には少なくとも 2 つの「C」、少なくとも 1 つの「CS」が必要です。など) NP サブグラフ同型問題に取り組む前に。つまり、テキストベースのメソッドはフィルターとして機能し、明らかな不一致を拒否できます。

存在するテキストの解決策を見つけようとしていますが、少し気が遠くなります。ストップ ワードもステミングも語順も気にしません。存在する多くの機能は必要ありません。「C」が 2 回出現するか 3 回出現するかを知ることが重要なので、単語ベクトルを保持する機能が必要です。

自分に最も適したテキスト検索エンジンはどれですか? 特にMahoutでの作業では、Luceneのように見えます. ドキュメントのどの部分を見るべきか、または関連するチュートリアルをお勧めできますか? 私が見つけたものは、全文検索用で、ステミングやその他の必要のない機能を備えています。

4

3 に答える 3

1

Hmm... don't really know what are SMARTS, or how chemical similarity actually work. If you want to use lucene, first consider using solr. Since your data is in graphs, you can take a look at neo4j with the solr component. Also, would this problem be more closely related to document near duplicates? For helping with that there are a number of algorithms LSH, Spotsigs, shingling, and simhash. Wish I could be of more help.

于 2011-01-14T14:29:54.800 に答える
1

編集：私はこれをよりよく理解したかもしれません。文字列として表されたグラフを比較したい。文字列には、繰り返される可能性のある「単語」があります。Lucene を使用することもできますが、その場合は、Solr を使用することをお勧めします。基本的に、各 Solr ドキュメントは単一のフィールドで構成されます。フィールドには文字列が含まれます。これを展開することをお勧めしC CますC:2。スペースを使用して単語を区切る場合は、WhiteSpaceAnalyzer を使用できます。別のセパレーターを使用する場合は、カスタム アナライザーを作成する必要がある場合がありますが、これはそれほど難しくありません。

これは良い考えですか？私はわかりません。理由は次のとおりです。

  1. Lucene (および Solr) は、コサインの類似性をそのまま使用するのではなく、コサイン、TF/IDF、およびブール値のスコアリングをいくつかの特定の変更を加えて混合したLucene Similarityを使用します。これはほとんどのテキストのユースケースでうまく機能しますが、必要なものとは異なる場合があります。
  2. 異なる検索からのヒットを比較する必要がありますか? その場合、すべての検索を最大値 1 に正規化するため、Solr を使用して行うのは困難です。

データベースの小さなサンプルとして、Solr を試してみることをお勧めします。Solr が機能する場合は、問題ありません。そうでない場合は、シングリングと最小ハッシュがおそらく最適です。Rajaraman と Ullman による Mining of Massive Datasetsは、これらの主題に関する最近の無料の本です。読むことをお勧めします。山のようなデータから類似の文字列を検索する方法について説明します。差別化要因は次のとおりだと思います。比較的大きな交差点が必要ですか。その場合は、シングリングと最小ハッシュを使用してください。そうでない場合は、おそらくSolrで十分です。

于 2011-01-15T21:45:09.753 に答える
0

ルセンは使用しないでください。またはSolr。内部モデルは時代遅れで、石畳です。彼らは良い仕事をしていますが。BM25F が完全にサポートされている (テキスト エンジン内でマップする場合) 最小限の基準を持つエンジンを検索します。スケーラビリティとパフォーマンス、および低コストのサポート コミュニティが必要な場合は、率直に言って、SQL Server とキューブを使用します。SQL Server のライセンスは、完全な障害になる可能性があります。幸運を。

于 2011-01-15T00:08:45.850 に答える