検索結果の品質向上 Elasticsearch入門

Slide 1

Slide 1 text

検索結果の品質向上 Elasticsearch 入門守谷純之介 APプロダクト開発グループ

Slide 2

Slide 2 text

自己紹介守谷純之介（モリヤジュンノスケ）・Qass: 検索チーム・Bazz: 自動応答BOTチーム

Slide 3

Slide 3 text

Bazz: 自動応答BOT https://help.jalan.net/s/

Slide 4

Slide 4 text

検索 It's like looking for a needle in the haystack.

Slide 5

Slide 5 text

アジェンダ • 検索とは何か？ • 転置インデックスとは何か？ • 転置インデックスを実装するには？ • 分散検索とは何か？ • Term とは何か？ • 良い検索結果とは何か？ • 検索結果のスコアとは何か？ • 良いランキングとは何か？ • 良いランキングを作るとは何か？

Slide 6

Slide 6 text

Slide 7

Slide 7 text

1. アルゴリズムの設計と解析検索ってどんな分野？ The Art of Computer Programming, Volume 3: Sorting and Searching • 1968年から刊行 • 全７巻予定 • 2019年現在第4巻まで

Slide 8

Slide 8 text

1. アルゴリズムの設計と解析検索ってどんな分野？ Introduction to Algorithms 代表的な教科書の地位は ← に奪われる。 RSAのR

Slide 9

Slide 9 text

2. 情報検索（Information Retrieval） Introduction to Information Retrieval Modern Information Retrieval スタンフォード大学の授業 CS 276 Information Retrieval and Web Search の教科書 http://web.stanford.edu/class/cs276/ 検索ってどんな分野？

Slide 10

Slide 10 text

Java で実装された検索ライブラリ利用 $ grep $ awk $ sed の index の index 今日のターゲット検索を実現するアプリケーションは？

Slide 11

Slide 11 text

特徴＼タイプ逐次検索 Index 型検索事前処理なし（コスト小）あり（コスト大）検索速度時間大時間小メモリー使用量メモリー小メモリー大典型的な手法 • grep • Knuth–Morris– Pratt 法 • Boyer-Moore 法 • 転置インデックス • N-gramインデックス • 形態素インデックス２つの検索タイプ ★ 今日のターゲット

Slide 12

Slide 12 text

Java で実装された検索ライブラリ利用 $ grep $ awk $ sed の index の index 検索を実現するアプリケーションは？逐次型 Index 型

Slide 13

Slide 13 text

株式会社リクルートテクノロジーズ

Slide 14

Slide 14 text

Java で実装された検索ライブラリ利用 $ grep $ awk $ sed の index の index 検索とは何か？逐次型 Index 型

Slide 15

Slide 15 text

逐次検索

Slide 16

Slide 16 text

… GPLでライセンスされていた。Linuxカーネル自体は240万行で、これは… 検索対象検索クエリー「Linux」 Linux 逐次検索

Slide 17

Slide 17 text

Index 型検索

Slide 18

Slide 18 text

2つのフェーズ Index 型検索 Indexing Search

Slide 19

Slide 19 text

Linuxは、狭義にはLinux カーネル、広義には… 検索対象最新版となるLinux4.20のリリース Index Index 型検索：Indexing＝事前準備 Linux カーネルリリース 1 2 1 1 2 2

Slide 20

Slide 20 text

検索対象 Index Index 型検索：Indexing＝準備完了 Linux カーネルリリース 1 1 2 2

Slide 21

Slide 21 text

AND 検索 Index Index 型検索：Search＝検索実行 Linux カーネルリリース 1 1 2 2 Linux AND カーネル ∩ Merge 1 2 2 1

Slide 22

Slide 22 text

OR 検索 Index Index 型検索：Search＝検索実行 Linux カーネルリリース 1 1 2 2 ∩ Merge 2 1 リリース OR カーネル 1 2

Slide 23

Slide 23 text

Index 型検索における Merge はコアであり、コストが超高い

Slide 24

Slide 24 text

2つのフェーズ Index 型検索 Indexing Search

Slide 25

Slide 25 text

• 大規模なデータを扱うサービスでは Index 型検索を導入 • Index 型検索は転置インデックスで実装

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Inverted Index （転置インデックス）

Slide 28

Slide 28 text

特性 Inverted Index (転置インデックス) 1. ドキュメントに含まれる特性をキー (全文検索などでは Term) にして、集合を紐付ける (リスト構造＝Posting List) 2. ドキュメントのリストをソート済み 3. 通常は単語の現れた位置情報も格納 (フレーズ検索) Index Linux カーネルリリース 1 1 2 2

Slide 29

Slide 29 text

Inverted Index の検索戦略

Slide 30

Slide 30 text

特性 Inverted Index (転置インデックス) 1. TAAT ＝ Term At A Time 2. DAAT ＝ Document At A Time Index Linux カーネルリリース 1 1 2 2

Slide 31

Slide 31 text

特性 Inverted Index (転置インデックス) 1. TAAT ＝ Term At A Time ＝一品ずつ食べる＝洋食 2. DAAT ＝ Document At A Time ＝全部少しずつ食べる＝和食

Slide 32

Slide 32 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】Term At A Time（訳：一度にタームを） • Term (転置インデックスのキー) 毎にリストを取得してマージ • ひとつのキー毎に処理 • 洋食 UNIX BSD mmap kernel Linux ① ② TAAT (Term At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 33

Slide 33 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】AND 検索（Linux AND mmap） • 件数の少ないキーから accumulator (マージ用リスト) を作成 • AND 検索の場合、accumulator のサイズは、もっとも件数の少ないリストより大きくなることはない。 UNIX BSD mmap kernel Linux TAAT (Term At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7 ① ②

Slide 34

Slide 34 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】AND 検索（Linux AND mmap） 1. 「mmap」のリストから accumulator を作成 = [1, 5, …] 2. 「Linux」のリストを accumulator にマージ「1」はある？⇒ある！⇒ stay 「5」はある？⇒ある！⇒ stay (「3」はもう見ない) UNIX BSD mmap kernel Linux TAAT (Term At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7 ① ②

Slide 35

Slide 35 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】OR 検索（Linux OR mmap） 1. どれでもよいのでキーから accumulator を作成 2. 重複を除いて全てのキーから全部のリストをマージする UNIX BSD mmap kernel Linux TAAT (Term At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7 ① ②

Slide 36

Slide 36 text

特性 Inverted Index (転置インデックス) 1. TAAT ＝ Term At A Time ＝一品ずつ食べる＝洋食 2. DAAT ＝ Document At A Time ＝全部少しずつ食べる＝和食

Slide 37

Slide 37 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】Document At A Time（訳：一度にドキュメントを） • Document (転置インデックスのリストのアイテム) 毎にリストを取得してマージ • ひとつのドキュメント毎に処理 • 和食 UNIX BSD mmap kernel Linux DAAT (Document At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 38

Slide 38 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】AND 検索（mmap AND Linux） • Term (mmap と Linux) 毎にカーソルを準備 • 各カーソルを移動し、共通のドキュメントを発見を発見したら、 accumulator に追加 UNIX BSD mmap kernel Linux DAAT (Document At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 39

Slide 39 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】AND 検索（mmap AND Linux） accumulator = [] UNIX BSD mmap kernel Linux DAAT (Document At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 40

Slide 40 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】AND 検索（mmap AND Linux） accumulator = [1] UNIX BSD mmap kernel Linux DAAT (Document At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 41

Slide 41 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】AND 検索（mmap AND Linux） accumulator = [1, 5] UNIX BSD mmap kernel Linux DAAT (Document At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 42

Slide 42 text

50,241件 10,320件 520件 30,483件 500,020件【戦略】OR 検索（mmap AND Linux） • なんでも良いので、accumulator を作る • カーソルを動かして、全ての要素を重複なく追加 UNIX BSD mmap kernel Linux DAAT (Document At A Time) 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 43

Slide 43 text

特性 TAAT and DAAT • メモリ使用量が多いのは TAAT • だた、OR 検索ではほぼ差はない • かなりプリミティブな作り

Slide 44

Slide 44 text

今でも効率的なアルゴリズムの研究が続いている TAAT and DAAT S. Ding and T. Suel. Faster top-k document retrieval using block-max indexes. In Proceedings of the 34th Annual International ACM SIGIR Conference on Research and development in Information Retrieval, pages 993-1002, 2011. ↑の成果は Lucene 8 (2019/3/14 リリース) で実装参考 https://fosdem.org/2019/schedule/event/apache_lucene_solr_8/attachments/slides/3325/export/events /attachments/apache_lucene_solr_8/slides/3325/SchindlerLucene8Slides.pdf 参考: https://medium.com/@mocobeta/lucene-8-%E3%81%AE-top-k- %E3%82%AF%E3%82%A8%E3%83%AA%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%E3%82%B7%E3%83%B3%E3 %82%B0%E6%9C%80%E9%81%A9%E5%8C%96-1-%E5%B0%8E%E5%85%A5%E7%B7%A8-5a6387076e8e

Slide 45

Slide 45 text

アジェンダ • 検索とは何か？ • 転置インデックスとは何か？ • 転置インデックスを実装するには？ • 分散検索とは何か？ • Term とは何か？ • ハイブリット index とは何か？ • 良い検索結果とは何か？ • 検索結果のスコアとは何か？ • 良いランキングとは何か？ • 良いランキングを作るとは何か？

Slide 46

Slide 46 text

転置インデックスをゼロから実装することは良くあること？ No あまり現実的ではない

Slide 47

Slide 47 text

Java の世界の検索システム Java で実装された検索ライブラリ利用

Slide 48

Slide 48 text

Lucene • 転置インデックスを提供 – DAAT（Document At A Time） • 非常にネイティブな検索の機能のみ提供 – 様々な検索機能 • RangeQuery、FuzzyQuery、BooleanQuery – スコアリング機能

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

転置インデックスを実装するには？アーキテクチャを知ろう！

Slide 52

Slide 52 text

アーキテクチャを知ろう！ Data Structure? Where and How?

Slide 53

Slide 53 text

アーキテクチャを知ろう！ Data Structure? Where and How?

Slide 54

Slide 54 text

転置インデックスに必要なことは？ • 速い • 小さい • デカくなっても性能劣化しない • 追加・更新・削除が容易 • 柔軟なクエリに対応

Slide 55

Slide 55 text

• B木（B-tree） • B+木（B+-tree） • B*木（B*-tree） • Skip-List 一般的なインデックスのデータ構造

Slide 56

Slide 56 text

4,820,483件 93,832,732件 car book Posting List (Skip List) 1 3 3 53395 53395 0件 100,000件

Slide 57

Slide 57 text

4,820,483件 93,832,732件 car book Posting List (Skip List) 1 3 3 53395 53395 0件 100,000件 100,000 回見て回る！！

Slide 58

Slide 58 text

4,820,483件 93,832,732件 car book Posting List (Skip List) 1 3 3 53395 53395 53395 53395 53395 53395 18395 291295 18395 291295 0件 100,000件

Slide 59

Slide 59 text

4,820,483件 93,832,732件 car book Posting List (Skip List) 1 3 3 53395 53395 53395 53395 53395 53395 18395 291295 18395 291295 見回る回数が少ない！！ ※ スキップの段数に依存 ※ スキップの間隔に依存 0件 100,000件

Slide 60

Slide 60 text

Posting List (Skip List) • lucene-8.0.0/core/src/java/org/apache/lucene/codecs/MultiLevelSkipListReader.java • lucene-8.0.0/core/src/java/org/apache/lucene/codecs/MultiLevelSkipListWriter.java * Example for skipInterval = 3: * c (skip level 2) * c c c (skip level 1) * x x x x x x x x x x (skip level 0) * d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d (posting list) * 3 6 9 12 15 18 21 24 27 30 (df) * * d – document * x - skip data * c - skip data with child pointer

Slide 61

Slide 61 text

Lucene の転置インデックスファイルの詳細 Apache Lucene - Index File Formats: http://lucene.apache.org/core/8_0_0/core/org/apache/lucene/codecs/lucene80/package- summary.html#package.description

Slide 62

Slide 62 text

• B木（B-tree） • B+木（B+-tree） • B*木（B*-tree） • Skip-List 一般的なインデックスのデータ構造

Slide 63

Slide 63 text

インデックスのデータ構造: B+木 • 葉ノード（葉ブロック）がデータを表す • 内部ノード（内部ブロック）は index（データをもたない） • 各ノードは a 個以上 b 個以下（例では２個以上３個以下）のエントリを必ずもつ条件を満たすように、木の構造を変形する • 範囲指定のクエリに対して、強力に動作 • ブロックデバイス（葉ブロックと内部ブロックを格納）との相性が抜群 30 50 7 12 22 30 39 52 55 73 ブロック 15以上

Slide 64

Slide 64 text

• ブロック単位で読み書き • ブロックの大きさはブロックサイズ • ブロックサイズは結構大きい（Linux のデフォルトは 4 KB） • 1 bit 書き換えても、ブロックごと書き換えられる残念ながら SSD もブロックデバイスブロックデバイス

Slide 65

Slide 65 text

アーキテクチャを知ろう！ Data Structure? Where and How?

Slide 66

Slide 66 text

ブロックデバイス？直接メモリーに置くのでは？

Slide 67

Slide 67 text

無邪気にメモリ上に置く、のは現実的ではない

Slide 68

Slide 68 text

無邪気にメモリー上に置く、が現実的ではいくつかの理由 • ロードに時間がかかる • スワップアウトし、更に再ロードされるような場合、激烈な性能劣化 • 膨大なコンテクストスイッチ（ユーザー空間 vs カーネル空間） • ディスクのファイルキャッシュと、Java のヒープでの間の膨大なやり取り

Slide 69

Slide 69 text

Index 型検索における Merge はコアであり、コストが超高いマージをするメモリーも必要！

Slide 70

Slide 70 text

それでは実際どうしているの？

Slide 71

Slide 71 text

mmap

Slide 72

Slide 72 text

mmap • システムコール • システムムコールだけど、ユーザープロセスの仮想アドレス空間に作成されるので、コンテクストスイッチが少ない: （ユーザー空間 vs カーネル空間） • メモリマップトファイルとして扱えるので、追加・削除・更新が楽 • 複数のプロセス間で共有もできる • 【注意】Java の世界から逸脱している（Java のヒープ外でアロケートされてる） • 【おまけ】C で malloc すると内部では mmap が呼ばれる

Slide 73

Slide 73 text

0x00000 実メモリ 0x00000 プロセスA 実アドレス 0x00000 プロセスB 仮想アドレス仮想アドレス mmap ファイル

Slide 74

Slide 74 text

Elasticsearch の推奨設定 “The standard recommendation is to give 50% of the available memory to Elasticsearch heap, while leaving the other 50% free. It won’t go unused; Lucene will happily gobble up whatever is left over.” 【注意】Java の世界から逸脱している（Java のヒープ外でアロケートされてる）

Slide 75

Slide 75 text

Lucene の index 格納 https://lucene.apache.org/core/8_0_0/core/org/apache/lucene/store/FSDirectory.html org.apache.lucene.store（3種類選べる） 1. SimpleFSDirectory.java • java.nio.ByteBuffer 2. NIOFSDirectory.java • java.nio.ByteBuffer 3. MMapDirectory.java • java.nio.MappedByteBuffer mmap

Slide 76

Slide 76 text

util-mmap: Indeed の mmap • https://jp.engineering.indeedblog.com/blog/2015/02/util-mmap- %E3%81%A7%E3%83%A1%E3%83%A2%E3%83%AA%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0/ • https://github.com/indeedeng/util/tree/master/mmap MappedByteBuffer の既知の制約を克服: – 安全にアンマップできない – サイズが 2GB (int) を超えるファイルをマップできない – スレッドセーフではない

Slide 77

Slide 77 text

Disk からも情報を引き出す • ブロックサイズを意識して格納 • ディスクへのアクセスは猛烈に遅いがディスクキャッシュは早い • トレードオフが十分ならば圧縮して格納する

Slide 78

Slide 78 text

圧縮のトレードオフ読み込み完了 100MB/s 5,000KB 50ms 25ms 30GB/s =30,720MB/s 2,500KB 50%圧縮読み込み完了 15ms 10ms＝解凍

Slide 79

Slide 79 text

Lucene で利用できる圧縮形式 LZ4 https://lz4.github.io/lz4/ lucene-8.0.0/core/src/java/org/apache/lucene/codecs/compressing/LZ4.java https://gigazine.net/news/20120824-dragonquest-backstage-cedec2012/ • 圧縮率は弱いが、圧縮速度が速い • 色々なところで使われている: – OS: Linux, FreeBSD – Hadoop, Cassandra – Nintendo Switch – ドラゴンクエストXのセーブデータ

Slide 80

Slide 80 text

アーキテクチャを知ろう！ Data Structure? Where and How?

Slide 81

Slide 81 text

それでは Elasticsearch & Solrは何を提供してくれるの？ • RESTfull なAPIの提供 • 管理機能の提供 • クラスタリング機能を提供

Slide 82

Slide 82 text

検索を導入するからには膨大なドキュメントがあるはずだ！クラスタリングによる分散検索複数のマシンから構成されるクラスタで検索を提供

Slide 83

Slide 83 text

クラスタリングによる分散検索は Elasticsearch を例として説明

Slide 84

Slide 84 text

Slide 85

Slide 85 text

分散検索

Slide 86

Slide 86 text

50,241件 10,320件 520件 30,483件 500,020件 1. 同じキーが同じサーバーにいる必要がない ⇔ BSD が別のサーバーにあっても良い 2. マージさえできればよい ⇔ BSD が複数のサーバーにあってもよい UNIX BSD mmap kernel Linux 分散検索 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 87

Slide 87 text

50,241件 10,320件 520件 30,483件 500,020件 UNIX BSD mmap kernel Linux 分散検索: indexing 1 1 1 2 3 3 4 4 5 5 6 6 7 UNIX mmap Linux UNIX mmap Linux UNIX mmap Linux

Slide 88

Slide 88 text

分散検索 • 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ – シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング（デフォルト） – どのシャードに格納するのかは、あなた次第！

Slide 89

Slide 89 text

分散検索 • 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ – シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング（デフォルト） – どのシャードに格納するのかは、あなた次第！ Node Node Node

Slide 90

Slide 90 text

分散検索 • 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ – シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング（デフォルト） – どのシャードに格納するのかは、あなた次第！ Node Node Node A Shard C Shard B Shard C Shard A Shard B Shard

Slide 91

Slide 91 text

• 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ – シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング（デフォルト） – どのシャードに格納するのかは、あなた次第！シャード A, B, C 全部が生存欠損なしで検索続行分散検索: 可用性（Availability） Node Node Node A Shard C Shard B Shard C Shard A Shard B Shard

Slide 92

Slide 92 text

Node Node Node A Shard C Shard B Shard C Shard A Shard B Shard 分散検索: 負荷分散（Load Balance） • 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ – シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング（デフォルト） – どのシャードに格納するのかは、あなた次第！シャードA と B に関する検索シャードA と B に関する検索シャードA と B に関する検索

Slide 93

Slide 93 text

Node Node Node A Shard C Shard B Shard C Shard A Shard B Shard • 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ – シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング（デフォルト） – どのシャードに格納するのかは、あなた次第！ hash(XXX) mod (# of Shard) = C 分散検索: ルーティング Doc ID: XXX

Slide 94

Slide 94 text

Slide 95

Slide 95 text

分散検索: Index の構成 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 • サーバー（シャード）は本来非常に多い（数万台、ここでは３台） • シャードに含まれるドキュメント数には上限有り（100万等） • どのサーバーも、自分の担当の検索は非常に高速（対象が100万位しかないから） • 入り切らなくなってきたら、サーバーを足す（スケールアップではなく、スケールアウト） < 1000,000 < 1000,000 < 1000,000

Slide 96

Slide 96 text

分散検索: Two Phase Search, query and fetch Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 • query phase: どのサーバーにマッチする結果がどれだけあるのか？ ⇒ メモリ上＋ネットワークトラフィック小で解決 • fetch phase: 見つけた結果を整形（スニペット生成、等）して返却結果を作成 ⇒ 高負荷な処理を実行

Slide 97

Slide 97 text

分散検索: Two Phase Search, query and fetch 【重要】各サーバは他のサーバーの安いアイスクリームを知らない！！クエリー：アイスクリーム ORDER BY 安い順 LIMIT 3 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円

Slide 98

Slide 98 text

分散検索: Two Phase Search, query and fetch クエリー：アイスクリーム ORDER BY 安い順 LIMIT 3 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 [50, 120, 200] [10, 220, 320] [300, 500, 720] [10, 50, 120]

Slide 99

Slide 99 text

分散検索: Two Phase Search, query and fetch クエリー：アイスクリーム ORDER BY 安い順 LIMIT 3 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 [10, 50, 120]

Slide 100

Slide 100 text

分散検索: Two Phase Search, query and fetch Q: 100位〜102位まで取ってくるには？クエリー：アイスクリーム ORDER BY 安い順 LIMIT 3 OFFSET 100 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 A: 各サーバーから102件取得してくる

Slide 101

Slide 101 text

分散検索: Two Phase Search, query and fetch Q: 嘘でしょ？クエリー：アイスクリーム ORDER BY 安い順 LIMIT 3 OFFSET 100 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 A: 本当です。

Slide 102

Slide 102 text

分散検索: Two Phase Search, query and fetch Q: 事前に準備とかできないの？クエリー：アイスクリーム ORDER BY 安い順 LIMIT 3 OFFSET 100 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 A: できないです…

Slide 103

Slide 103 text

分散検索: Two Phase Search, query and fetch クエリー:（アイスクリーム AND すいか味）ORDER BY 安い順 LIMIT 3 OFFSET 100 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円

Slide 104

Slide 104 text

Slide 105

Slide 105 text

ちゃんと話していないこと

Slide 106

Slide 106 text

Term （転置インデックスのキー）

Slide 107

Slide 107 text

Slide 108

Slide 108 text

50,241件 10,320件 520件 30,483件 500,020件 UNIX BSD mmap kernel Linux 転置インデックス 1 1 1 2 3 3 4 4 5 5 6 6 7

Slide 109

Slide 109 text

Lucene の世界の Term と Token Token = Term（＝文字列＋フィールド）＋開始位置＋終了位置 • lucene/core/src/java/org/apache/lucene/index/Term.java • lucene/core/src/java/org/apache/lucene/analysis/Token.java これはどう作るの？！ Lucene の世界では Tokenizer が分割をしてくれる！

Slide 110

Slide 110 text

Lucene の Tokenizer • ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactory • PatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenize rFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

英語の Tokenize は超簡単 “Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases.” WhitespaceTokenizer “Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases.”

Slide 114

Slide 114 text

日本語の Tokenize は… “Elasticsearchは、様々なユースケースを解決する、分散型RESTful 検索 /分析エンジンです。” ？ “Elasticsearchは、様々なユースケースを解決する、分散型RESTful 検索 /分析エンジンです。” ？単純には分割できない？

Slide 115

Slide 115 text

Slide 116

Slide 116 text

Ngram Tokenizer 一定の長さの文字列単位で分割「敵に塩を送る」 • Unigram: 1文字単位 ⇒ 「敵」「に」「塩」「を」「送」「る」 • Bigram: 2文字単位 ⇒「敵に」「に塩」「塩を」「を送」「送る」 • Trigram: 3文字単位 ⇒「敵に塩」「に塩を」「塩を送」「を送る」 Q: Bigram で「塩」を検索可能？！ A: No… 検索できない ⇒ N-gram ならば 2-1gram

Slide 117

Slide 117 text

Ngram Tokenizer Unigram vs Trigram 「敵に塩を」 • 長さ3以上の term ならできることに変わりはなし（「塩」は検索できない） • どんどん大きくなると、完全一致のようになり、検索とは何か？という問題になる（6-gramでは「敵に塩を送」さえ検索できない） • 速度には差がでる（Unigram より Trigram の方が速い） 4個タームのマージ vs 2個のタームのマージ「敵」「に」「塩」「を」vs 「敵に塩」「に塩を」 ※「に」「を」のPosting List などは非常に大きい（はず）

Slide 118

Slide 118 text

Japanese Tokenizer（Kuromoji）形態素解析エンジン。辞書ベースで分割。「敵に塩を送った」 Surface form Part-of-Speech Base form Reading Pronunciation 敵名詞,一般,*,* 敵テキテキに助詞,格助詞,一般,* に二二塩名詞,一般,*,* 塩シオシオを助詞,格助詞,一般,* をヲヲ送っ動詞,自立,*,* 送るオクッオクッた助動詞,*,*,* たタタ

Slide 119

Slide 119 text

Ngram vs 形態素解析効果＼方法 Ngram 形態素解析取りこぼし：「目黒」で「中目黒」 hit! = Good! No hit. = Bad… レレバンシー：「京都」で「東京都」 hit! = Bad… No hit. = Good! Indexのサイズ大 = Bad… 小 = Good! それぞれ、良いところと悪いところがある解決策：両方をもつハイブリッド index

Slide 120

Slide 120 text

Slide 121

Slide 121 text

ちょっとここで脱線

Slide 122

Slide 122 text

文字列のことばかりだけど、数値の場合の検索は？

Slide 123

Slide 123 text

B+木の数値に対するクエリー • Q: 15以上のアイテムがほしい！ • 更にQ: 価格が1000円以下のアイテムがほしい！ • またまたQ: 年式が2013以降で、色は赤っぽくて、高さが200… 30 50 7 12 22 30 39 52 55 73 15以上

Slide 124

Slide 124 text

A: コサイン類似度

Slide 125

Slide 125 text

コサイン類似度価格色鮮度商品A 商品B 商品C クエリー cos の値が • 1 に近ければ、類似している • 0 に近ければ、類似していない

Slide 126

Slide 126 text

A: コサイン類似度 , = cos = ∙ | | ∙ | |

Slide 127

Slide 127 text

Slide 128

Slide 128 text

検索結果の良い、悪いって何？

Slide 129

Slide 129 text

Precision and Recall

Slide 130

Slide 130 text

適合率と再現率 Precision and Recall 検索結果が適合性：どれほど正確か？再現性：どれほど網羅しているか？

Slide 131

Slide 131 text

理想の検索結果 C 実際の検索結果 B 適合率と再現率 A 適合率＝ B A 再現率＝ C A

Slide 132

Slide 132 text

理想の検索結果 C 実際の検索結果 B A 適合率＝ B A 意味：どれほど正確か？実際の検索結果（B）に理想の結果（A）が含まれている割合適合率

Slide 133

Slide 133 text

理想の検索結果 C 実際の検索結果 B 再現率 A 再現率＝ C A 意味：どれほど網羅しているか？理想の検索結果（C）の内、実際の検索索結果として取得できた（A）割合

Slide 134

Slide 134 text

理想の検索結果 C 実際の検索結果 B 適合率と再現率 A 再現率＝ C A 適合率＝ B A • 適合率：正確性＝ノイズを含まない比率 • 再現率：網羅性＝取りこぼしが少ない比率

Slide 135

Slide 135 text

理想の検索結果 C 実際の検索結果 B 適合率と再現率 A クエリー「東京都」適合率↑ 再現率↑ 再現率＝ C A 適合率＝ B A

Slide 136

Slide 136 text

C B 適合率と再現率 A 適合率↓ 再現率↓ 再現率＝ C A 適合率＝ B A 実際の検索結果理想の検索結果クエリー「東京都」

Slide 137

Slide 137 text

C B 適合率と再現率 A 適合率↓ 再現率→ 再現率＝ C A 適合率＝ B A 実際の検索結果理想の検索結果クエリー「京都」

Slide 138

Slide 138 text

C B 適合率と再現率 A 適合率↑ 再現率→ 再現率＝ C A 適合率＝ B A 実際の検索結果理想の検索結果クエリー「京都」

Slide 139

Slide 139 text

C B 適合率と再現率 A 残念ながら、適合率と再現率はトレードオフ再現率＝ C A 適合率＝ B A 実際の検索結果理想の検索結果

Slide 140

Slide 140 text

C B 適合率と再現率 A • 適合率を上げれば再現率は下がり、 • 再現率を上げれば適合率が下がる。再現率＝ C A 適合率＝ B A 実際の検索結果理想の検索結果

Slide 141

Slide 141 text

理想の検索結果 C 実際の検索結果 B A 再現率＝ C A 適合率＝ B A ＝1 • 実際の検索結果が全て理想の検索結果 • ただし、取りこぼしが非常に多い＝理想の検索結果の一部しか返却できていないなんでも正しい1件しか返却しない！ ⇒ 最高極端な適合率 • 適合率を上げれば再現率は下がり、 • 再現率を上げれば適合率が下がる。

Slide 142

Slide 142 text

理想の検索結果 C 実際の検索結果 B A ＝1 • 実際の検索結果が全ての理想の検索結果が含まれる • ただし、非常にノイズが多い＝理想の検索結果以外の結果が多く含まれている極端な再現率 • 適合率を上げれば再現率は下がり、 • 再現率を上げれば適合率が下がる。適合率＝ B A 再現率＝ C A なんでも全件返却する！ ⇒ 最高

Slide 143

Slide 143 text

理想の検索結果 C 実際の検索結果 B 適合率と再現率 A 再現率＝ C 適合率＝ B 適合率（正確性）と再現率（網羅性）のバランスが重要 A A

Slide 144

Slide 144 text

F-measure：適合率と再現率のバランス F-measure の値が大きければ、バランスのとれた良い結果 F-measure ＝適合率（ 1 ＋再現率 1 ） 2 適合率＝ B A 再現率＝ C A

Slide 145

Slide 145 text

ところで…

Slide 146

Slide 146 text

理想の検索結果 C 実際の検索結果 B 適合率と再現率の理想の検索結果とは？ A 適合率＝ B A 再現率＝ C A

Slide 147

Slide 147 text

適合率と再現率の非現実性 • そもそも「理想の検索結果」とは？ – 機械的に作ることが可能ならば、それを検索結果してしまえば良い • 実際に10万件の結果がある場合、評価可能？！ – メジャーなクエリー1万件ある場合、評価が必要な件数は10億件 • 検索にヒットしなかった結果も評価しないといけない… – 全部で100万件あり、10万件ヒットしたとしても、残りの90万件も「理想の検索結果」か否かを評価…

Slide 148

Slide 148 text

そもそも、検索結果を全件見る？！

Slide 149

Slide 149 text

0 5000000 10000000 15000000 20000000 25000000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 検索結果の順位 (x軸)とクリック数 (y軸) のサンプル

Slide 150

Slide 150 text

愚直に適合率と再現率を上げるのではなく、必要とされる順序で検索結果を返すことが重要

Slide 151

Slide 151 text

ランキング

Slide 152

Slide 152 text

検索結果の一般的な評価？ • クエリー「目黒」で、検索結果に「中目黒」を含めるべきか否か？！ – なかなか分からない • クエリー「京都」で、検索結果に「東京都」を含めるべきか？！ – 含めるべきではない（だろう） • 答えはあるのか？ – 多分、一般的な解はない • どうすればいいのか？

Slide 153

Slide 153 text

結局ランキング

Slide 154

Slide 154 text

ところでこの _score って何だ？！

Slide 155

Slide 155 text

結果：目黒 { "_score" : 656.68774, "_source" : { "nikki_kuromoji" : "雪の目黒", "nikki_ngram" : "雪の目黒“ } }, { "_score" : 23.361103, "_source" : { "nikki_kuromoji" : "雨の中目黒", "nikki_ngram" : "雨の中目黒“ } }

Slide 156

Slide 156 text

Slide 157

Slide 157 text

TF-IDF and Okapi BM25b

Slide 158

Slide 158 text

Okapi BM25: 1980年代から90年代に、ロンドン大学シティ校で作られた Okapi 検索システムで実装されたから

Slide 159

Slide 159 text

TF-IDF and Okapi BM25b • 何なの？ – アルゴリズム • 入力は？ – 文章の集合 • 出力は？ – 各文章の各単語にスコアを付与 • スコアは何を表すの？ – 各文章の各単語の重要度

Slide 160

Slide 160 text

TF-IDF and Okapi BM25b • 何なの？ – アルゴリズム • 入力は？ – 文章の集合 • 出力は？ – 各文章の各単語にスコアを付与 • スコアは何を表すの？ – 各文章の各単語の重要度 Linux: 0.3 Windows:0.1 ぶり: 4.2 Linux: 1.3 Windows:2.3 まぐろ: 3.8 Linux: 5.4 FreeBSD:10.3 大根: 2.1

Slide 161

Slide 161 text

困ってる人：「文章が沢山あるのだけど、それぞれの文章に特徴的なタグを付けられないかな。」私達：「OK！TF-IDF か Okapi BM25b を使えば瞬殺」

Slide 162

Slide 162 text

２つの文章での「Linux」 Linux Linux（リナックス、他の読みは後述）は、 UnixライクなOSカーネルである）。 OS オペレーティングシステム（英語: Operating System、 OS、オーエス）とは、コンピュータのオペレーション（操作・運用・運転）のために、ソフトウェアの中でも基本的、中核的位置づけのシステムソフトウェアである。通常、OSメーカーが組み上げたコンピュータプログラムの集合として、作成され提供されている。 … フリーなOSは、Linux、FreeBSD… … どちらの文章が「Linux」に関して重要度が高いか？！＜直感的？定量的

Slide 163

Slide 163 text

TF-IDF

Slide 164

Slide 164 text

TF-IDF • TF＝Term Frequency＝Termの頻度あるドキュメントの中で、どれだけそのTerm が出現したか？ ⇒ いっぱい出てくる単語は重要だ • IDF：IDF＝Inverse Document Frequency＝逆文章頻度あるTerm が全体の中でどれほどレアか？ ⇒ レアな単語は重要だ • TF-IDF = TF×IDF あるドキュメント D の中の、Term T がどれほど重要か？は、（TF: D の中でのT の頻出度）×（IDF: T の全体でのレア度）

Slide 165

Slide 165 text

TF-IDF：TF＝Term Frequency＝Termの頻度 Linux Linux（リナックス、他の読みは後述）は、 UnixライクなOSカーネルである）。 Linux: 2 リナックス: 1 読み: 1 Unix: 1 一つの文章に現れる Term の出現回数沢山出現すればそれだけ重要

Slide 166

Slide 166 text

TF-IDF：IDF＝Inverse Document Frequency＝逆文章頻度 • Linux • である IDF ＝ log Term T が現れる文章数総文章数 • 野菜 • である • 野菜 • がある • Linux • がある • 肉 • である IDF(Linux) ＝ log 2 5 ＝ 0.39 IDF(である) ＝ log 3 5 ＝ 0.22 ＞定量的 Linux である

Slide 167

Slide 167 text

TF-IDF：IDF＝Inverse Document Frequency＝逆文章頻度 • 逆である意味は？！ – 現れるドキュメントが、多ければ多いほど、重要度を下げたい（逆比例：「である」等は小、「しめ鯖」等は大） • log を取る意味は？！ – 非常に大きな総文章数の場合のためのノーマライズ（ノーマラナイズしないとTFの意味がなくなる） IDF ＝ log Term T が現れる文章数総文章数

Slide 168

Slide 168 text

TF-IDF あるドキュメント D の中の、 Term T がどれほど重要か？は、（TF: D の中での T の頻出度） × （IDF: 文章全体での T のレア度）

Slide 169

Slide 169 text

TF-IDFの注意（良いところ）あるドキュメント D に対して Term が異なれば、TF-IDFも異なるしめ鯖 ⇒ 0.8492 Linux ⇒ 0.0234 月刊 Linux 2018/04/24 号今月の月刊 Linux では、カーネルの特集を… …ところでしめ鯖は美味しいですね。僕も…

Slide 170

Slide 170 text

Okapi BM25b

Slide 171

Slide 171 text

BM25: TF-IDFが不都合な場合 Linux Linux（リナックス、他の読みは後述）は、 UnixライクなOSカーネルである）。 Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux Linux … TF(Linux) ＝ 14,352 TF(Linux) ＝2 ＞これは不都合注）IDFはどちらも一緒

Slide 172

Slide 172 text

Slide 173

Slide 173 text

BM25の定義 Linux Linux（リナックス、他の読みは後述）は、 UnixライクなOSカーネルである）。・TF = 単語(Linux)の出現数・IDF = 単語レア度(Linuxのレア度) ・DL = ドキュメントの単語数(23) ・avgDL = 全てのドキュメントの単語数の平均 (=320) ・２つのパラメータk1, b k1 は 2 が最も最適と言われている b は 0.75 が最も最適と言われている BM25(Linux) ＝TF × IDF × TF+k1 ×(1-b+b× ) k1 + 1 avgDL DL

Slide 174

Slide 174 text

BM25の意味 BM25(Linux) ＝TF × IDF × TF+k1 ×(1-b+b× ) k1 + 1 avgDL DL 単に単語を沢山もつ場合は減点↓ 単語を沢山もつ場合は一つの単語の価値を減点↓ 単語を沢山もつ場合は減点だがそれが平均に対して小さければ加点↑ ・TF = 単語の出現数・IDF = 単語レア度・DL = ドキュメントの単語数・avgDL = 全てのドキュメントの単語数の平均

Slide 175

Slide 175 text

BM25 and TF-IDF Linux はフリーのOSカーネルであり、… FreeBSDは Unix系のオープンソースの … 今年のじゃがいもはとても不作だった。日本ではこの時期のブリを特に「寒ブリ」と呼ぶ • Linux: 23 • OS: 11 • カーネル: 17 • は: 0.331 • あり: 3.65 • の: 0.003 • です: 0.0001 • は: 0.000053 • の: 0.023 • FreeBSD: 65 • OS: 9 • カーネル: 5 • じゃがいも: 42 • 不作: 58 • 今年: 2 • だった:0.003 • は: 0.00428 • の: 0.00084 • 寒ブリ: 90 • 日本: 3 • 時期: 1.8 • 特に: 0.2 • の: 0.00189 レアではないワードはスコア小特徴的 Term はスコア大

Slide 176

Slide 176 text

そもそもTF-IDF を何故計算していたのか？

Slide 177

Slide 177 text

Slide 178

Slide 178 text

結局ランキング

Slide 179

Slide 179 text

Slide 180

Slide 180 text

Slide 181

Slide 181 text

Slide 182

Slide 182 text

ランキングをより良くしてみよう！

Slide 183

Slide 183 text

その前に…

Slide 184

Slide 184 text

より良いランキングってなんだ？！

Slide 185

Slide 185 text

定量的に良いランキングを評価する指標： nDCG

Slide 186

Slide 186 text

nDCG • nDCG (= normalized Discounted Cumulative Gain) • 直訳すると「正規化された効果減少の累積報酬」 • ランキングの精度評価指標 • ランキングを行うシステムの評価に利用できるので、特に、検索だけがターゲットではない。例）レコメンドシステム、広告システム • nDCG も理想のランキングとの乖離具合を数値化

Slide 187

Slide 187 text

レコメンド

Slide 188

Slide 188 text

Slide 189

Slide 189 text

nDCG：実際の検索結果クエリー「からし明太子」 ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子

Slide 190

Slide 190 text

nDCG：実際のカスタマーの行動クエリー「からし明太子」 ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入

Slide 191

Slide 191 text

ちょっと脱線「クリック」と「購入」って何だ？

Slide 192

Slide 192 text

CTR と CVR 表示された ※ サービスによって定義はまちまちクリックされた購入された

Slide 193

Slide 193 text

PV: page view, 表示された回数表示されたクリックされた購入された

Slide 194

Slide 194 text

表示されたクリックされた購入された CTR = 表示された回数クリックされた回数 (Click Through Rate)

Slide 195

Slide 195 text

表示されたクリックされた購入された CVR = 表示された回数購入された回数 (Conversion Rate)

Slide 196

Slide 196 text

Slide 197

Slide 197 text

Slide 198

Slide 198 text

仮設「上位の結果の方がクリックされやすい」

Slide 199

Slide 199 text

Slide 200

Slide 200 text

nDCG：実際の結果クエリー「からし明太子」 ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入

Slide 201

Slide 201 text

nDCG：理想の結果クエリー「からし明太子」 ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入

Slide 202

Slide 202 text

nDCG：理想の結果（並べ替えだけでは不十分）クエリー「からし明太子」 ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入元々1位だったアドバンテージを考慮していない

Slide 203

Slide 203 text

nDCGは順位のアドバンテージを考慮した評価

Slide 204

Slide 204 text

nDCG：スコア ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入 1. 各順位の結果はスコアをもっている（例クリック数＋購入数×100） S1=150 S2=110 S3=45 S5=60 S4=250

Slide 205

Slide 205 text

nDCG：Top5 の DCG ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 2. 各順位に応じて、ペナルティを与え、全体のスコアを計算 DCG5＝ S1 + + + … log2 S2 log3 S3

Slide 206

Slide 206 text

nDCG：理想の結果のDCG=iDCG (ideal DCG) ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 3. スコア順のDCG = iDCG を求める ⇒ DCG が MAX

Slide 207

Slide 207 text

nDCG = iDCG（理想のDCG） DCG（現実のDCG）

Slide 208

Slide 208 text

現実の DCG ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 DCG5＝ S1 + + + … = 439.23 log2 S2 log3 S3

Slide 209

Slide 209 text

理想の DCG ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 DCG5＝ S1 + + + … = 518.78 log2 S2 log3 S3

Slide 210

Slide 210 text

nDCG = 518.78 439.23 = 0.84 理想の結果の84%

Slide 211

Slide 211 text

ちょっと改善した DCG ① 送料無料福岡加工辛子明太子ゴールデンサイズ ② 当店人気No.1 明太子！【送料無料】てんこ盛り訳あり ③ からし明太子高菜 80g×2パック ④【送料無料】かねふく ★極上辛子明太子 1kg ⑤ マ・マーあえるだけパスタソース逸品からし明太子クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 DCG5＝ S1 + + + … = 489.23 log2 S2 log3 S3

Slide 212

Slide 212 text

nDCG = 518.78 489.23 = 0.94 理想の結果の94%

Slide 213

Slide 213 text

nDCG の違いクリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 nDCG=0.84 nDCG=0.94

Slide 214

Slide 214 text

ランキングの良さを定量的に評価できるようになりました

Slide 215

Slide 215 text

定量的に評価できることが大事で、手法はサービスによって選べば吉 • nDCG • Precision@k • MAP (Mean Average Precision) • MMR (Maximal Marginal Relevance)

Slide 216

Slide 216 text

定量的に評価できると何が良いのか？！ 1. 客観性 2. 再現性 3. 実証性 4. 機械学習の対象にできる

Slide 217

Slide 217 text

MLR= Machine Learning Ranking クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 クリック購入クリック購入クリック購入クリック購入クリック購入 S1=150 S2=110 S3=45 S5=60 S4=250 nDCG=0.84 nDCG=1.00 理想を目指してパラメータ調整

Slide 218

Slide 218 text

Slide 219

Slide 219 text

Slide 220

Slide 220 text

ジャンルにヒットしたらスコアを上げる • filter がメインの検索（「鈴木」さんを検索） • bool が関連のあるワードとのマッチによるスコアアップ（「野球」や「MLB」に関連する方） { "query": { "bool": { "should": [ { "match_phrase": { "contents": { "boost":1000, "query": "野球" } } }, { "match_phrase": { "contents": { "boost":1000, "query": "MLB” } } } ], "minimum_should_match": 0, "filter": { "bool": { "should": [ { "match_phrase": { "contents": "鈴木" } } ] } } } } }