1

私はデータベースにある構造化されたレコードのかなり小さなコーパスを持っています。Webフォーム（テーブルスキーマと同じように構造化されている）を介して送信された単一のレコードに含まれる情報のごく一部を考えると（これをテストレコードと呼びます）、リストをすばやく作成する必要があります。テストレコードと一致する可能性が最も高いレコード、および検索用語がレコードとどの程度一致しているかの信頼性の見積もりを提供します。この検索の主な目的は、コーパス内のレコードと重複するレコードを誰かが入力しようとしているかどうかを検出することです。テストレコードが重複する可能性は十分にあり、テストレコードが重複しない可能性は十分にあります。

レコードの幅は約12000バイトで、レコードの総数は約150,000です。テーブルスキーマには110の列があり、検索の95％が最も一般的に検索される上位5％の列になります。

データは、名前、住所、電話番号、その他の業界固有の番号などです。コーパスとテストレコードの両方で、手作業で入力され、個々のフィールド内で半構造化されています。最初は「列に手作業で重みを付け、その中の単語トークンを一致させる」と赤面するかもしれませんが、それはそれほど簡単ではありません。私もそう思いました。電話番号を取得した場合、それは完全に一致することを示していると思いました。問題は、トークンの頻度が桁違いに変化しないフォームに単一のフィールドがないことです。電話番号は、コーパスに100回、またはコーパスに1回表示される場合があります。他の分野についても同じことが言えます。これにより、フィールドレベルでの重み付けは実用的ではなくなります。きちんとしたマッチングを得るには、よりきめ細かいアプローチが必要です。

私の最初の計画は、ハッシュのハッシュを作成することでした。最上位はフィールド名です。次に、特定のフィールドのコーパスからすべての情報を選択し、そこに含まれるデータをクリーンアップして、サニタイズされたデータをトークン化し、トークンをキーとして、頻度を値として、第2レベルでトークンをハッシュします。

頻度カウントを重みとして使用します。参照コーパス内のトークンの頻度が高いほど、テストレコードで見つかった場合に、そのトークンに付加する重みは少なくなります。

私の最初の質問は、部屋の統計家に向けたものです。頻度を重みとしてどのように使用しますか？n、レコード数f（t）、トークンtがコーパスに出現する頻度、レコードがオリジナルで重複ではない確率o、および確率pの間に正確な数学的関係がありますか？テストレコードは、実際にはテストが与えられたレコードxであり、xには同じフィールドに同じtが含まれていますか？複数のフィールドにわたる複数のトークンの一致の関係はどうですか？

あることを心から疑っていますが、魔法の要素でいっぱいの完全に恣意的なハックよりも、私を近づけるものはありますか？

それを除けば、誰かがこれを行う方法を持っていますか？

トークン頻度ルックアップテーブルなど、データベース内の別のテーブルを維持する必要のない他の提案に特に熱心です。

4

1 に答える 1

0

おそらく、この異なるが類似したSOの質問からいくつかのアイデアを得ることができます： calcuting-context-sensitive-text-correlation。

目前の問題により具体的に、ここにいくつかの考えとアイデアがあります：

まず、非常に偏った使用法（使用量の95％をカバーするのは6〜10個の属性のみ）を認めることで、属性に非対称的な取り組みを適用できます。つまり、プログラミング時間と実行時間の両方の観点から、より多くの投資を行うことができます。 100個の追加属性よりもこれらのいくつかの属性を処理するためのCPU割り当て。

データベース内の重複の可能性を照合するための入力として提供される比較的少量のデータ、通常使用される比較的少数の属性セット、およびこれらの明らかに一般的なセマンティクス（電話番号、住所、名前など）は、手作りのソリューションを示唆しています完全に機械学習に基づくものではありません。

注：その後、多くの提案をすべての属性に適用する必要はありません（これらの提案のうち、事実上すべての使用法をカバーしているのは12未満であるため、少なくとも最初は他の属性に多くの投資をする意味はありません。

  • データを正規化する
    元のフィールド値を変更することが許可されていない場合は、対応する列を「norm_xxx」列に複製することができます。ここで、xxxは元の名前です。
    何を、どのように正規化するかは、属性ごとに異なる場合があります。データのような「フリーテキスト」の場合は、先頭にも末尾にもスペースがなく、単語間にスペースが1つだけあり、タブや印刷できない文字がないことを確認してください。すべて大文字またはすべて小文字のいずれかを使用します（元の/表示用のテキストに混合が含まれている可能性がある場合は、大文字と小文字を統一できるため、処理が高速になります）。より具体的には、住所や会社名については、一般的な用語を標準形式（STREET、ST、STなどのST）に変換できます（ユーザーの検索条件にも適用されるため、このリストを必ず保持してください） ）。正規化の一部として、いくつかのノイズワードを完全に削除することもできます（会社名の末尾にあるCO、INC、GMBHなど）
  • いくつかの計算列を作成します
    。たとえば、末尾のワイルドカードで検索できる属性について、逆にテキストを含む列を作成します。
  • 一部の属性には、Soundexのような変換を使用することを検討してください。
  • フルテキストインデックス、個別に、すべてテキストのような列
  • よく使用される6〜10列すべてにプレーン（SQL）インデックスを作成する

上記はすべて、実際に試合を行うための単なるオフライン時間の準備です。今..ユーザーは彼/彼女のクエリを入力します...ここにそれを処理する方法に関するいくつかのアイデアがあります

  • それを正当化する検索基準を正規化する
  • いくつかの検索を実行します...
    これは少し注意が必要です。これらの検索を実行するには、部分的に矛盾するいくつかの目標があります。「潜在的な一致」の数を大幅に減らしたいと考えています。150,000レコードすべてをユーザー指定の基準と完全に1対1で比較することは事実上非現実的です。たとえば、一部のマッチングロジックは、データベースの特定のレコードのフィールドと検索条件の間の編集距離を計算することを意味する場合があります。また、会社名のタイプミスが原因で「一致する可能性のある」リストからレコードを除外しないようにします...最後に、一致する可能性のあるリストをランク付けして提供します。
    これらの検索を実行する方法は、いくつかの事前定義されたヒューリスティックに従います（戦略設計パターンがそのためにうまく機能し、ユーザーが入力した入力に応じて、検索の実行方法に柔軟性を持たせることができます）。一言で言えば、最も選択的/関連性のある属性で最も選択的な単語を検索し、見つかった「ヒット」の数に基づいて、他の検索結果と「OR」（和集合）または「AND」のいずれかを見つけます。百の記録。
  • 「一致する可能性のある」レコードの各属性と対応する検索条件の間の類似度値を計算します。おそらく、この値に係数を適用します（会社名[部分]が都市の一致に一致すると言うために、より多くの重みを置くことができます）
  • 完全なレコードの全体的な類似性の値を集計します（完全な検索基準と比較して）

  • レビューのために、類似性値の特定のしきい値を超えるレコードをエンドユーザーに表示します

    最後に、部分的に自動化されたプロセスがあり、エンドユーザーから提供されたフィードバックに基づいていくつかのパラメーターを変更できます。（これを行うのは非常に難しいです。他の投稿のためにこれを保持します;-)）

于 2010-03-12T02:41:58.803 に答える