転置インデックスと転置インデックスを理解する

1.前に書く

おすすめの分野では、検索に便利な転置インデックスの設定についてよく耳にしますが、これについてはいつも戸惑っています。転置インデックスとは何か、正のインデックスとは何ですか。転置インデックスを確立しますか？どこですか？したがって、この記事では、情報を参照することで、これら2つの概念を簡単に理解します。

以下は、私が確認した情報に基づく私の理解ですが、正しくない可能性があります。

順索引と転置索引は、文書検索システムの分野で重要な2つのデータ構造であり、実際には効率的なクエリのための2つの異なる組織形態であると理解しています。確立されるのは、文書と単語の関係マッピング関係です。

• ポジティブインデックス：文档->关键词ドキュメント番号を入力すると、ドキュメントの内容やドキュメントのキーワードなどの情報が取得されます。より一般的です。つまり{doc: [word1, word2, ..]}、推奨事項に配置されている場合は、対応する可能性があります。に{item: [feature1, feature2, ...]}
• 転置インデックス：キーワード->ドキュメント間のマッピング。つまり、キーワードを入力すると、対応するドキュメント情報が見つかります。これは、より一般的{word: [doc1, doc2, ...]}であり、推奨事項に入れられます。{user_id: [item1, item2, ..]}

これはドキュメント検索の分野から来ているので、ドキュメント検索から始めましょう。

検索エンジンでは、各ファイルはファイルIDに対応し、ファイルの内容は一連のキーワードのセットとして表されます。

2.正の指数

ドキュメント（ページ）のキーワードとの対応関係を確立します。構造は次のとおりです。

正排索引： 由文档指向关键词

文档--> 单词1 ,单词2

单词1 出现的次数  单词出现的位置； 单词2 单词2出现的位置  ...

正排索引: 在搜索栏中输入id查词条(已知id)

画像に置き換えられた場合：

ユーザーが検索ボックスに「キーワード」を入力すると、フォワードインデックス（フォワードインデックス）しかない場合、インデックスデータベース内のすべてのドキュメントをスキャンしてすべてのドキュメントを見つける必要があります。 「キーワード」を含むドキュメント次に、スコアリングモデルに従ってドキュメントがスコアリングされ、ランキングがユーザーに表示されます。

しかし？インターネット上の検索エンジンに含まれるドキュメントの数は天文学的なものであり、そのようなインデックス構造は、ランキング結果をリアルタイムで返すという要件を満たすことができません。

したがって、検索エンジンは順方向インデックスを転置インデックスに再構築します。つまり、ファイルIDからキーワードへのマッピングをキーワードからファイルIDへのマッピングに変換します。各キーワードは一連のファイルに対応します。これらのファイルこのキーワードは次の場所に表示されます。すべて 。

ここで、推奨フィールドを比較すると、ここのドキュメントは推奨したいアイテムのようですか？また、ここのキーワードは、推奨フィールドのuser_idとは異なり、上記のキーワードに従って関連ドキュメントを提供するプロセスです。 user_idが指定されている場合、レコメンダーシステムは関連するitem_listsを彼に推奨しますか？類推の重要性について。

3.転置インデックス

ユーザーが検索エンジンでキーワードを検索すると、検索エンジンはそのキーワードに関連するドキュメント（ページ）をユーザーに表示します。このプロセスは転置インデックスであり、キーワードはドキュメントまたはファイルを指します。

構造は次のとおりです。

倒排索引： 由关键词指向文档

单词1--->文档1,文档2，文档3

单词2--->文档1，文档2

倒排索引: 将搜索框中的词进行搜索查到哪些id包含这个词，再查这些id(通过分词查id)

単語のキーワードから、ドキュメントを見つけます。図に示されている単語は次のとおりです。

したがって、ユーザーが特定のキーワードを検索すると、システムは転置インデックスでそのキーワードをすぐに見つけ、そのキーワードを含むページをすぐに見つけます。

転置インデックスには、検索エンジン、大規模データベースインデックス、ドキュメント検索、マルチメディア検索など、さまざまなアプリケーションシナリオがあります。

正排索引： 文档 --> 单词
倒排索引: 单词 --> 文档

4.簡単な例

小さな例を使用して、順方向インデックスと逆方向インデックスを見てみましょう。

ドキュメントコレクションに5つのドキュメントが含まれ、それぞれに次のコンテンツが含まれているとします（下の最初のリンクの画像）。

次に、正のインデックスの場合、次の方法で保存する必要があります。

文档编号      正排列表
1      谷歌->地图->之父->跳槽->Facebook
2      谷歌->地图->之父->加盟->Facebook
3      谷歌->....
4
5

そして転置インデックス：

さらに、索引付けシステムは、より多くの情報を記録することもできます。たとえば、文書番号だけでなく、単語頻度情報（TF）も、単語に対応する反転リスト、つまり単語の回数に記録できます。特定のドキュメントに表示されます。この情報を記録する理由は、検索結果を並べ替えるときにクエリとドキュメントの類似性を計算するときに、単語の頻度情報が非常に重要な計算要素であるためです。

より完全な転置インデックス構造は、より多くの情報を記録することもできます。ドキュメント番号と単語頻度を記録することに加えて、各単語に対応するドキュメント頻度情報を追加で記録し、特定の転置リストに単語を記録するものもあります。 。

• ドキュメント頻度情報：ドキュメントコレクション内の特定の単語を含むドキュメントの数を表します。この情報は検索結果のランキングでも非常に重要な要素であるため、この情報が記録されます。
• 特定のドキュメントに表示される単語の位置情報を記録する必要はありません。記録されている場合とされていない場合があります。

たとえば、「Las」という単語を例にとると、単語番号は8、ドキュメント頻度は2です。これは、この単語を含むドキュメントセット全体に2つのドキュメントがあり、対応する反転リストは{（ 3; 1; <4>）、（5; 1; <4>）}、ここでの形式（ドキュメント番号;ドキュメント内の出現頻度;出現位置）。ドキュメント内の特定の単語の頻度とその単語を含むドキュメントの数があれば、各ドキュメント内の単語のTF-IDF値を計算でき、ランキングの重要な指標として使用できることを理解しています。

5.推奨事項に戻る

5.1材料の転送行情報

推奨フィールドでは、インデックス最適化戦略がリコール側、つまり候補を探すときによく使用されます。

リソースプールでは、各資料（ニュース、商品、曲）がIDに対応し、資料は一連のフィールドコンテンツのコレクションとして表されます。タイトル、カテゴリ、地理的な場所、価格などを表すフィールドがあります。次の図は、特定のタイプの材料リソースプールテーブルの構造の一部を示しています。

各マテリアルの一意のIDを使用して、このマテリアルのさまざまな属性フィールドを取得し、このマテリアルの詳細をクエリできます。これは、通常の意味での正のインデックスです。

では、転置インデックスとは何ですか？転置インデックスを理解するには、実際のアプリケーションシナリオを理解する必要があります。レコメンデーションシステムのリコールでは、前述のように、実際には、特定の機能、テーマ、またはキーワードの下にあるすべての資料をレコメンデーション候補セットとして取得する必要があります。このときは逆になりますが、これらの特性を持った素材を探すことが出発点で、いわゆる転置インデックスです。

5.2協調フィルタリングにおける逆行のアイデア

これは、ユーザーの協調フィルタリングのアイデアに基づいて推奨リストを生成したときに、転置インデックスという用語に初めて触れた場所でもあります。

ユーザーの協調フィルタリングが現在のユーザーに与えられていることはわかっています。類似性に従ってこのユーザーに類似する上位n人のユーザーを見つけ、これらのn人のユーザーがクリックした製品を確認してから、どの製品を推奨するかを確認する必要があります。

ユーザーの行動ログによると、4人のユーザーA、B、C、Dがクリックした商品を次のように取得したとします：

現時点では、ユーザーの類似性を求める一般的な考え方は、外層がユーザーを横断することです、また、内層はユーザーをトラバースします。内層のユーザーごとに、外層の現在のユーザーと一緒にクリックされた製品の数を確認するか、共同でクリックされた製品のベクトルを保存します。ユーザーをメモリにトラバースした後、類似性を計算できます。疑似コードは次のようになります。

for user1, item_list1 in user_item.items():
	for user2, item_list2 in user_item.items():
		if user1 == user2: continue
		con_click_action = 0
		for item in item_list1:
			if item in item_list2:  # 共同点击
				con_click_action += 1  
		
		# 计算当前用户相似性
		similarity{
    
    user1}{
    
    user2} = con_click_action / math.sqrt(len(item_list1) * len(item_iist2)

多くのユーザーがいる場合、これは非常に時間がかかります。実際、彼らは同じアイテムを操作していません。つまり、ほとんどの場合、2人のユーザーが同じアイテムを評価することはめったにありません。非常に不経済です。

したがって、反転の考え方を変更し、ユーザーにアイテムの反転リストを作成し、アイテムごとに、アイテムを操作したユーザーのリストを保存できます。このような：

このとき、反転したテーブルを1回スキャンし、ユーザーリスト内の2人のユーザーに対応する位置要素の統計を蓄積して、すべてのユーザー間の同じアイテムに対する同時アクションの数、つまり、コサイン類似性。

for movie, users in movie_user.items():     # movid是movieID， users是set集合
    for u in users:           # 对于每个用户， 都得双层遍历
        for v in users:
            if u == v:
                continue
            user_sim_matrix.setdefault(u, {
    
    })      # 把字典的值设置为字典的形式
            user_sim_matrix[u].setdefault(v, 0)
            user_sim_matrix[u][v] += 1     # 这里统计两个用户对同一部电影产生行为的次数， 这个就是余弦相似度的分子

# 下面计算用户之间的相似性
for u, related_users in user_sim_matrix.items():
    for v, count in related_users.items():    # 这里面v是相关用户， count是共同对同一部电影打分的次数
        user_sim_matrix[u][v] = count / math.sqrt(len(trainSet[u]) * len(trainSet[v]))   # len 后面的就是用户对电影产生过行为的个数   

参照：

• 転置インデックスとは何ですか？
• 転置および転置インデックスの理解
• レコメンデーションシステムのインデックスの適用