問題タブ [inverted-index]

ウェブサイトに何千ものページがあり、解析して逆インデックスとして保存しました

資料

• docid (PK、FK)
• URL
• 文字カウント
• 単語数

Charactercount と wordcount は、長いドキュメントと短いドキュメントを区別するのに役立ちます。後で使用する可能性があります。

語

• ワード ID (PK、FK)
• 語
• doc_freq
• inverse_doc_freq

inverse_doc_freq の計算では、架空の高い数値 (100000000) を使用して、ドキュメント全体の再計算を防ぎます。

ロック

• ワードID
• ドシッド
• 単語頻度
• 重さ

(wordid と docid を組み合わせた一意)

重みは、タイトルの単語 + URL の単語 + 単語の頻度などの単純な基準で計算されたスコアです。

検索語に対する SQL クエリのフレーミングに問題があります。3単語検索の場合、私は次のようにしています

1. クエリを各単語に分割する
2. 各単語の inverse_doc_freq を確認し、IDF の低い単語を削除します (ストップ ワードの削除)
3. 残りの単語を語幹化します (まだ 3 つの単語が残っていると仮定します)
4. 各単語のクエリ

私が行き詰まっているのはステージ4です！私のSQLクエリは次のようなものです

SELECT d.docid,url,inverse_doc_freq,word_freq,weight from document d,word w,loc l WHERE d.docid=l.docid AND w.wordid=l.wordid AND (word='word1' OR word='word2' OR word='word3') ORDER BY weight DESC

ただし、返されたドキュメントは正しくありません。各単語のドキュメントを見つけるために 3 回検索してから、共通のドキュメントを見つけようとする必要があるかもしれませんが、どうすればよいでしょうか? 1 つの MySQL クエリのみを使用することは可能ですか? また、TF-IDFはどのように使用できますか?

次のように、invertedIndex のコードがあります。しかし、私はそれにあまり満足しておらず、どうすればよりコンパクトでPythonicにできるのか疑問に思っていました

(ちなみに、タイトルが完全なニシンである場合は申し訳ありません)

バックグラウンド：

Twitter Streaming API と ASP.NET SignalR を使用して、世界中のすべてのツイートのマップをリアルタイムで作成しています。Tweetinvi C# Twitter ライブラリを使用して、SignalR を使用してブラウザーにツイートを非同期的にプッシュしています。すべてが期待どおりに機能しています - http://dev.wherelionsroam.co.ukを参照してください。

開発の次のステップでは、スタンフォード自然言語解析ライブラリ ( http://nlp.stanford.edu/software/corenlp.shtml )、特に Named Entity Recognizer (CRFClassifier とも呼ばれる)を使用して、各ツイートのテキスト データを解析します。各ツイートから意味のあるメタデータ (言及された人、場所、組織) を抽出できること。望ましい結果は、多くの人が話している人、場所、組織を特定し (「トレンド」の概念と同様)、SignalR を使用してすべてのクライアントにブロードキャストできるようになることです。Twitter API にGET trendsメソッドがあることは承知していますが、それでは面白くないでしょうか?!

私のアプリの主なクラスは次のとおりです。

主なクラス:

TweetModel.cs (ストリーミング API からブロードキャストされたツイートに関するすべての情報を保持します):

抽象 NamedEntity クラス:

抽象 NamedEntity クラスをオーバーライドするクラスの例である Person クラス:

TweetParser クラス:

Named Entity Recognizer の説明:

NER 認識ライブラリのしくみは、"Luis Suarez" の "PERSON" や "New York" の "PLACE" などのタグを使用して、文章内の単語を分類することです。PERSONこの情報は、NER ライブラリによって単語に割り当てられたタグのタイプ ( 、LOCATION、の選択ORGANISATION)に応じて、NamedEntity クラスのサブクラスに格納されます。

問題：

私の質問は、「Luis Suarez」という用語の複数のバージョンが登場する可能性が高いことを考慮して (つまり、Luis Suarez、Luis Suárez)、どちらも独自の NamedEntity インスタンス (インスタンス内List<NamedEntity>、>親子関係を維持しながら、すべてのツイートから用語「Luis Suarez」の一致するTweetModelインスタンスをグループ化する最良の方法は何でしょうか。これは実質的に逆指数であると知らされましたが、この人物がどれほど十分な情報を持っていたかはわかりません!TweetModelList<NamedEntity>

構造の可視化:

この質問が不明確である場合は、本当に申し訳ありません。これ以上簡潔に表現することはできません。これまでの完全な src については、 https://github.com/adaam2/FinalUniProjectを参照してください。

こんにちは、xml コレクションからいくつかのドキュメントのインデックスを作成する小さなプログラムを作成しようとしています。tf-idf メソッドを使用します。私のプログラムがクエリを読み取ると、各ドキュメントの各単語のタプル ('tf-idf','docid') のリストが返されます。

これは例です:

この場合、ドキュメント 2 には 1 つの単語しか含まれていません。

ここで私の質問は次のとおりです。これらのドキュメントとクエリの間でドット積を実行する必要があることはわかっていますが、どうすればよいですか? クエリを重みのベクトルに変換するにはどうすればよいですか?

ありがとうございました。

逆索引付けが単語を索引付けするための良い方法であることは知っていますが、検索エンジンが実際にそれらをどのように保管するかについて混乱していますか? たとえば、「google」という単語がドキュメントに表示されている場合、頻度の異なる 2、4、6、8 の場合、それらをどこに保存する必要がありますか? 1対多の関係を持つデータベーステーブルは、それらを保存するのに役立ちますか?

json 応答結果から逆インデックスのような構造を生成しようとしていました。

[{"node":[{"node": [{"node": [{"id": "w"}], "id": "q"}], "id":"e"},{ "id":"r"},{"id":"t"}],"id":"y"}, {"id": "u"}]

これがサンプルのjsonデータです。私が試みているのは、各「id」オブジェクトのインデックスを追跡することだけです。たとえば、特定のサンプルでは、​​「id」が「u」に等しいオブジェクトのインデックスは [1] であり、「id」が「q」に等しいオブジェクトのインデックスは [0[0[0]]] です。

ここでの結果のインデックス表現は配列の形式であるため、それぞれ [1] と [0,0,0] になります。

私はすべてのためにこのコードを書きました。

このコードを実行すると、トレース中に各ノードの正しい結果が出力されますが、実行の最後に、インデックスクラス変数 ( dict object ) に奇妙な値が残り、それを理解できません。なぜですか?

これが実行結果です。これには、上記の jsonデータを使用しました。

ツリー = ツリー (データ)

そして、これを出力します：

y[0]

e [0, 0]

q [0, 0, 0]

w [0, 0, 0, 0]

r [0, 1]

t [0, 2]

あなた [1]

{'e': [0]、'q': [0]、'r': [0]、'u': [1]、't': [0]、'w': [0]、' y': [0]}

したがって、ここでは、「id」ごとに正しい結果のインデックス配列が出力されることがわかりますが、最後にクラス変数のインデックスが表示されているだけで、何がわかりません。

PS : 実際、私はこの種の個人的な問題を尋ねることを信じていませんが、私は一日中これと戦っています. 私は友人に同じことを尋ねました。

だから私はそれから学ぶための答えと教訓を待っています:)

前もって感謝します。

ユーザーからの自由形式のクエリが与えられた場合、場所のフレーズが含まれているかどうかを判断しようとしています。

例: フリーフォーム クエリ「カリフォルニア州サンフランシスコのニューヨーク スタイル ピザ」と、「デンバー コ」、「マイアミ フロリダ」、「ニューヨーク シティ ニューヨーク」、「サンフランシスコ カリフォルニア」などの場所のフレーズを含むドキュメントのインデックスが与えられた場合、「paris france」などの場合、一致はロケーション フレーズ「san francisco ca」を含むドキュメントになります。

ロケーション フレーズを含むインデックスには、別のドキュメントに許容される順列も含まれます。上記の例では、"san francisco ca"、"san francisco california"、および場合によっては "sf ca"、"bay area ca" など、すべてインデックス内の個別のドキュメントとして含めることができます。大文字と小文字の区別と句読点は前もって破棄されるため、「カリフォルニア州サンフランシスコのニューヨーク スタイルのピザ」というクエリは「カリフォルニア州サンフランシスコのニューヨーク スタイルのピザ」になります。

また、「都市」と「州」と「国」をさまざまなフィールドに含めるなど、特定のタイプのクエリでこれを機能させるために場所にインデックスを付けるためのより良い方法または必要な方法がある場合は、私が行うことができますそれもまた、私は提案を非常に受け入れています。

私がこれまでに試したこと：

1. プレーンな古い一致クエリ。最適に動作するように見えますが、順序付けは無視されます...「san francisco ca」は一致しますが、「ca francisco san」は一致しないはずです。位置も無視します。
2. フレーズ一致。入力クエリに余分な用語 (「ニューヨーク スタイルのピザ」) が含まれているため、一致するものが得られないため、まったく機能しません。
3. マルチフィールドマッチ、cross_fields オプション。一致クエリと同じ問題。順序と位置を無視します。これは、"city" と "state" などが異なるフィールドであるインデックスのバージョンで試みられました。
4. 浸透。まったく仕事に就けませんでした。呼び出し GET .../_percolate は、インデックス内のすべてのドキュメントを取得します。また、.percolator タイプのビルドは非常に遅く、バルク API を使用してインスタンスをクラッシュさせました (JVM メモリ 99%)。私のデータベースには約 100 万の場所があり、約 120K の場所で一貫してクラッシュする percolator には多すぎると思います。私が読んだことから、これはパーコレーターの適切な使用例ではないと思いますが、よくわかりません。

私が試していないこととその理由：

1. 帯状疱疹。特定の場所に含まれる用語の数は可変であり (つまり、「ダラス テキサス」、「サンフランシスコ カリフォルニア」、「ニューヨーク市、ニューヨーク」など)、帯状疱疹は特定の数の用語で機能するようです。
2. クエリ文字列。ユーザーがフレーズを二重引用符で囲む必要はありません。また、クエリ言語 (OR、AND など) も必要ありません。また、位置を無視します。

私はこの問題を解決するのに 3 ～ 4 日を費やしました。サンプルのクエリ/インデックス/マッピングは素晴らしいですが、使用する必要があるクエリの種類 (およびインデックス作成とマッピング) を教えてくれるだけでも非常に役立つので、少なくとも「適切なツリーを作成する」ことができます!

他のツールがオープンソースであり、自由に利用でき、適切にサポートされ、使用されている限り、ES と組み合わせて他のツールを使用することにオープンです。位置データベースには最大 100 万件のレコードが含まれています。

おまけ: ロケーション フレーズがある場合は、クエリの最後にあると想定しています。それを感知するか、それに応じて結果を後押しする何らかの方法は素晴らしいでしょう. これを絶対的な要件にしたくないことに注意してください。ユーザーが「ニューヨーク スタイルのピザを提供しているサンフランシスコ カリフォルニア州のピザ店が欲しい」というクエリを送信した場合、前述のインデックスが指定された唯一の有効なロケーション フレーズは「サンフランシスコ カリフォルニア州」であり、一致するはずです。

ボーナス 2X: 各場所の人口情報があります。人口が多い場合に結果をわずかにブーストする方法も素晴らしいでしょう (field_value_factor 関数と ln1p 修飾子を使用して function_score を試してみましたが、うまく機能しているように見えますが、パーコレーターを使用した場合にどのように機能するかはわかりません)。

BONUS 3X!: 「san francsco」などのわずかなタイプミスに対応できるとよいでしょう。

ElasticSearch 1.3.2 を使用しています。

ありがとうございました！！

編集:明確にするために、ここでうまく説明されているように、インデックス付きのフレーズがクエリよりも短い場合、フレーズ検索を探していますが、残念ながら完全には解決されていません:

Solr: インデックス付きフレーズがクエリより短い場合のフレーズ検索