18

私には次の要件があります:-

私は多くの(たとえば100万)値(名前)を持っています。ユーザーは検索文字列を入力します。

ユーザーが名前を正しくつづることは期待していません。

だから、私は一種のグーグルを「あなたは意味しましたか」にしたいです。これにより、データストアからのすべての可能な値が一覧表示されます。ここに似ているが同じではない質問があります。これは私の質問に答えませんでした。

私の質問:-1)これらのデータをRDBMSに保存することはお勧めできません。その場合、SQLクエリにフィルターを適用しません。そして、私は全表スキャンをしなければなりません。では、この状況では、データをどのように保存する必要がありますか?

2)2番目の質問はこれと同じです。しかし、私の質問を完全にするために、大規模なデータセットを検索するにはどうすればよいですか?データセットにFrankyという名前があるとします。ユーザーがPhrankyと入力した場合、Frankyと一致させるにはどうすればよいですか?すべての名前をループする必要がありますか?

レーベンシュタイン距離に出くわしました。これは、可能な文字列を見つけるための優れた手法になります。しかし、繰り返しになりますが、私の質問は、データストアからの100万個すべての値を操作する必要があるかどうかです。

3)私は知っています、Googleはユーザーの行動を監視することによってそれを行います。しかし、私はユーザーの行動を見ずにそれをやりたいと思っています。つまり、距離アルゴリズムを使用して、まだわかりません。前者の方法では、最初に大量の検索が必要になるためです。

4)カークブロードハーストが以下の回答で指摘したように、2つの可能なシナリオがあります:-

  • 単語のタイプミス(距離編集アルゴリズム)
  • 単語を知らず、推測しているユーザー(音声一致アルゴリズム)

私はこれらの両方に興味があります。それらは実際には2つの別個のものです。たとえば、SeanとShawnは同じように聞こえますが、編集距離は3です。タイプミスと見なすには高すぎます。

4

8 に答える 8

7

Soundexアルゴリズムは、これを支援する場合があります。

http://en.wikipedia.org/wiki/Soundex

各名前のsoundex値を事前に生成してデータベースに保存し、それをインデックスに登録して、テーブルをスキャンする必要がないようにすることができます。

于 2009-08-16T17:10:13.743 に答える
6

Bitapアルゴリズムは、テキストの本文でおおよその一致を見つけるように設計されています。たぶん、それを使って一致の可能性を計算することができます。(これはレーベンシュタイン距離に基づいています)

(更新:Ben Sの 回答を読んだ後(おそらく既存のソリューションを使用してくださいaspell)が進むべき道です)


他の人が言ったように、グーグルはユーザーが自分自身を修正するのを見ることによって自動修正を行います。someting" "(sic)を検索し、すぐに " something"を検索すると、最初のクエリが正しくなかった可能性が非常に高くなります。これを検出するための可能なヒューリスティックは次のとおりです。

  • ユーザーが短い時間枠で2回の検索を行った場合、
  • 最初のクエリで結果が得られなかった(またはユーザーが何もクリックしなかった)
  • 2番目のクエリは有用な結果をもたらしました
  • 2つのクエリは似ています(レーベンシュタイン距離が小さい)

次に、2番目のクエリは、保存して他のユーザーに提示できる最初のクエリの可能な改良版です。

これらの提案が役立つために十分なデータを収集するには、おそらく多くのクエリが必要であることに注意してください。

于 2009-08-16T17:40:40.787 に答える
4

これには、既存のソリューションの使用を検討します。

名前のカスタム辞書を使用したAspellは、これに適している可能性があります。辞書ファイルを生成すると、提案をすばやく行うために必要なすべての情報が事前に計算されます。

于 2009-08-16T17:23:05.150 に答える
3

これは古い問題であり、 WarrenTeitelmanによってXeroxAltoに実装されたことで有名なDWIM(Do What I Mean)です。問題が発音に基づいている場合は、次のような調査用紙が役立ちます。

J.ZobelおよびP.Dart、「音声文字列照合:情報検索からの教訓」、Proc。第19回年次インター。ACMSIGIR会議 情報検索における研究開発(SIGIR'96)、1996年8月、166-172ページ。

情報検索に携わっている友人から、クヌースが説明したサウンデックスは今では非常に時代遅れだと言われています。

于 2009-08-16T17:21:31.847 に答える
3

Solrまたは同様の検索サーバーを使用するだけで、このテーマの専門家である必要はありません。スペル候補のリストを使用して、提案された各結果で検索を実行し、現在の検索クエリよりも多くの結果がある場合は、それを「意味がありますか」の結果として追加します。(これにより、より関連性の高いヒットを実際に返さない偽のスペルの提案を防ぐことができます。)このように、Solrには、最初の「意味がありますか」の提供を行うために多くのデータを収集する必要はありません。特定のクエリの結果を手動で調整できます。

通常、このタイプの検索にはRDBMSを使用せず、代わりに、この目的を目的とした読み取り専用の少し古いデータベースに依存します。(Solrは、基盤となるLuceneエンジンとデータベースに使いやすいプログラミングインターフェイスと構成を追加します。)私が働いている会社のWebサイトでは、夜間サービスがRDBMSから変更されたレコードを選択し、それらをドキュメントとしてSolrにプッシュします。わずかな労力で、検索ボックスが製品、カスタマーレビュー、Webサイトページ、ブログエントリを非常に効率的に検索し、検索結果にスペルの提案を提供したり、NewEggで見られるようなファセットブラウジングを提供したりできるシステムがあります。 Netflix、またはHome Depotで、サーバー(特にRDBMS)にほとんど負担がかかりません。(Zappoの[新しいサイト]とNetflixの両方がSolrを内部で使用していると思いますが、

シナリオでは、Solrインデックスに名前のリストを入力し、構成ファイルで適切なマッチングアルゴリズムを選択します。

于 2009-08-16T18:26:49.457 に答える
2

あなたが参照する質問への回答の1つと同じように、Peter Norvigの優れたソリューションは、Pythonコードを使用してこれに対応します。グーグルはおそらくいくつかの方法で提案を照会します、しかし彼らが彼らのために行っているのはたくさんのデータです。確かに、膨大なクエリログを使用してユーザーの行動をモデル化できますが、テキストデータを使用して、どの修正がより一般的であるかを調べることで、単語の最も可能性の高い正しいスペルを見つけることもできます。この単語sometingは辞書に表示されません。一般的なスペルミスですが、正しいスペルの方がはるかに一般的です。類似の単語を見つけたら、スペルミスに最も近く、特定のコンテキストで最も可能性の高い単語が必要です。

Norvigの解決策は、Project Gutenbergから数冊の本のコーパスを取得し、出現する単語を数えることです。それらの単語から、彼は単語の確率を推定することもできる辞書を作成します(COUNT(word) / COUNT(all words))。これをすべてストレートハッシュとして保存すると、アクセスは高速になりますが、保存が問題になる可能性があるため、接尾辞の試行などを使用することもできます。アクセス時間は同じですが(ハッシュに基づいて実装する場合)、ストレージ要件ははるかに少なくなります。

次に、彼はスペルミスの単語の簡単な編集を生成し(文字を削除、追加、または置換することにより)、コーパスの辞書を使用して可能性のリストを制約します。これは、編集距離(Levenshtein距離など)の考え方に基づいており、ほとんどのスペルミスは編集距離2以下で発生するという単純なヒューリスティックです。ニーズと計算能力に応じて、これを広げることができます。

彼が可能な単語を手に入れたら、彼はコーパスから最も可能性の高い単語を見つけます。それがあなたの提案です。モデルを改善するために追加できるものはたくさんあります。たとえば、スペルミスの文字のキーボード距離を考慮して確率を調整することもできます。もちろん、これはユーザーが英語のQWERTYキーボードを使用していることを前提としています。たとえば、とを転置する方が、eとをq転置するよりも可能性が高くなりeますl

于 2009-08-24T02:54:36.867 に答える
1

Soundexを推奨している人にとって、それは非常に時代遅れです。メタフォン(シンプル)またはダブルメタフォン(コンプレックス)の方がはるかに優れています。それが本当に名前データである場合、名前がヨーロッパ風であるか、少なくとも音声である場合は、正常に機能するはずです。

検索に関しては、Aspellやその他のスマートデータ構造を使用するのではなく、自分でロールする場合は...可能な一致を事前に計算するのは、単純な場合はO(n ^ 2)ですが、まったく一致している場合は、「音素」のオーバーラップが必要です。2つでもかまいません。この事前インデックス作成ステップ(偽陽性率が低い)は、複雑さを大幅に軽減できます(実際には、O(30 ^ 2 * k ^ 2)のようになります。ここで、kは<< nです)。

于 2009-09-01T01:57:03.300 に答える
1

対処する必要のある2つの問題が考えられます(または、選択した場合は対処しないでください)。

  1. 単語のタイプミス(距離編集アルゴリズム)
  2. 単語を知らず、推測しているユーザー(音声一致アルゴリズム)

これらの両方に興味がありますか、それともどちらか一方に興味がありますか?それらは実際には2つの別個のものです。たとえば、SeanとShawnは同じように聞こえますが、編集距離は3です。タイプミスと見なすには高すぎます。

単語の数に事前にインデックスを付けて、関連する回答のみを提案していることを確認する必要があります(ealdentの提案と同様)。たとえば、私が入力した場合sith、私が意味するかどうか尋ねられることを期待するかもしれませんがsmith、私が入力smithした場合、提案することは意味がありませんsith単語の相対的な可能性を測定し、より可能性の高い単語のみを提案するアルゴリズムを決定します。

ルーズマッチングでの私の経験は、シンプルですが重要な学習を強化しました-必要な数のインデックス/ふるいレイヤーを実行し、2つまたは3つ以上を含めることを恐れないでください。たとえば、正しい文字で終わらないものはすべてカリングします。非常に集中的な操作であるため、実際には、可能な限り最小のデータセットに対してのみ編集距離の計算を実行する必要があります。

したがって、O(n)、O(nlogn)、およびO(n ^ 2)アルゴリズムがある場合は、3つすべてをこの順序で実行して、「良好な見通し」のみを重いアルゴリズムに渡すようにします。 。

于 2009-09-01T02:33:51.670 に答える