Tweet
Tweet

Slide 1

Slide 1 text

検索結果の品質向上 守谷 純之介 （株）リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室 データプロダクトユニット データプロダクトマネジメント１部 検索エンジニアリング２グループ © Recruit Co., Ltd., 2024. 1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

目標 • プリミティブな検索エンジンを作ってみよう • どのようなデータ構造を採用すればいいの？ • どんな実装をすれば良いの？ • 分散システムの良いところ・悪いところを、 作って理解しよう • 検索品質の改善とは何か？理解しよう • どんなことが問題になるのか？ • そもそも品質って何なのか？ © Recruit Co., Ltd., 2024. 3

Slide 4

Slide 4 text

自己紹介 守谷 純之介（モリヤ ジュンノスケ） • 2002〜2003: ポスドク研究員 • 2003〜2004: ベンチャー企業の何でも屋さん • 2004〜2013: ポータルサイトの検索屋さん • 2013〜: リクルート • Qass: 検索チーム • Bazz: 自動応答 Bot © Recruit Co., Ltd., 2024. 4 Compiler が好きです。 何の貢献もできないけど… https://www.saiensu.co.jp/search/?isbn=97 8-4-7819-1229-5&y=2009

Slide 5

Slide 5 text

自己紹介 © Recruit Co., Ltd., 2024. 5 趣味はギター なんですが、 ギターよりもエフェクターを いじっている時間が長くて、 半田ごて握っている時間の方 が長いかも…

Slide 6

Slide 6 text

Qass: 検索チームのシンプル API サービスを担当 © Recruit Co., Ltd., 2024. 6 サジェスト or オートコンプリート

Slide 7

Slide 7 text

Qass: 検索チームのシンプル API サービスを担当 © Recruit Co., Ltd., 2024. 7 https://atmarkit.itmedia.co.jp/ait/series/29245/

Slide 8

Slide 8 text

Qass: 検索チームのシンプル API サービスを担当 © Recruit Co., Ltd., 2024. 8 ちょっと変わった検索… と言うか、こちらが主流になる？！ Document かわいい 美味しい 和風 Document には 書いていないけど…

Slide 9

Slide 9 text

Qass: 検索チームのシンプル API サービスを担当 © Recruit Co., Ltd., 2024. 9 軽トラ https://www.carsensor.net/usedcar/freeword/%E8%BB%BD%E3%83%88%E3%83%A9/index.html Query Rewriter

Slide 10

Slide 10 text

Qass: 検索チームのシンプル API サービスを担当 © Recruit Co., Ltd., 2024. 10 ちょっと変わった検索… と言うか、こっちが世界の潮流になりそう… Document A Document を 分差表現にして… [0.23, 0.54,…] [0.22, 0.58,…] ユーザーの好み Document A Document B Document C Document B Document C

Slide 11

Slide 11 text

コサイン類似度 © Recruit Co., Ltd., 2024. 11 𝑠𝑖𝑚 𝑎, 𝑏 = cos 𝜃 = 𝑎 ∙ 𝑏 | 𝑎 | ∙ | 𝑏 | 𝑎 𝑏 𝜃 Document A ユーザーの好み

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

今日は扱わない検索 © Recruit Co., Ltd., 2024. 13 The Art of Computer Programming, Volume 3: Sorting and Searching The Flexible Pattern Matching in Strings: Practical On-Line Search Algorithms for Texts and Biological Sequences $ grep $ awk $ sed 正規表現

Slide 14

Slide 14 text

今日扱う検索 ① © Recruit Co., Ltd., 2024. 14 Introduction to Information Retrieval Modern Information Retrieval Information Retrieval: Implementing and Evaluating Search Engines IR＝情報検索 https://www.cambridge.org/highereducatio n/books/introduction-to-information- retrieval/669D108D20F556C5C30957D63B5 AB65C#overview Modern Information Retrieval - Home (uchile.cl) https://plg.uwaterloo.ca/~ir/ir/book/

Slide 15

Slide 15 text

今日扱う検索 ② © Recruit Co., Ltd., 2024. 15 IR＝情報検索 情報検索 :検索エンジンの実装と評価 情報検索の基礎

Slide 16

Slide 16 text

今日扱う検索 ③ © Recruit Co., Ltd., 2024. 16 の index の index ちょっとだけ

Slide 17

Slide 17 text

今日扱う検索！！ © Recruit Co., Ltd., 2024. 17 Java で実装された 検索ライブラリ Lucene 利用 利用 Solr 検索エンジン、全文検索

Slide 18

Slide 18 text

今日扱う検索！！ © Recruit Co., Ltd., 2024. 18 Elasticsearch server Apache Solr 入門 旧) 株式会社リクルートテクノロジーズ (監修)

Slide 19

Slide 19 text

© Recruit Co., Ltd., 2024. 19 検索チーム (Qass) の 河野晋策 さんが共著の 『検索システム ― 実務者のための開発改善ガイド ブック』 2022年04月22日発売！！ 今日の講義は（ずっと寝ていても）この本を読めばOK https://www.lambdanote.com/blogs/news/ir-system 今日扱う検索！！！！！

Slide 20

Slide 20 text

２つの検索の Pros & Cons © Recruit Co., Ltd., 2024. 20 特徴＼タイプ 逐次検索 Index 型検索 事前処理 Pros: なし（コスト小） Cons: あり（コスト大） 検索速度 Cons: 時間大 Pros: 時間小 メモリー使用量 Pros: メモリー小 Cons: メモリー大 典型的な手法 grep: • Knuth–Morris–Pratt 法 • Boyer-Moore 法 転置インデックス • N-gramインデックス • 形態素インデックス 全てはユーザー体験向 上の為に！！

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

転置インデックスでの２つのフェーズ © Recruit Co., Ltd., 2024. 22 Search & Indexing Apache Book Car Dog … 10, 25 … 2, 57 … 15, 17 …98, 101 本の索引と一緒

Slide 23

Slide 23 text

Indexing: 事前準備＝転置 index の作成 © Recruit Co., Ltd., 2024. 23 Linuxは、狭義には Linuxカーネル、広義に は… 検索対象 最新版となるLinux4.20 のリリース 転置 index Linux カーネル リリース A B A A B B

Slide 24

Slide 24 text

Search: AND 検索 © Recruit Co., Ltd., 2024. 24 転置 index Linux カーネル リリース A A B B 検索クエリ: Linux AND カーネル ∩ Merge [A, B] [B] [B]

Slide 25

Slide 25 text

Search: OR 検索 © Recruit Co., Ltd., 2024. 25 転置 index Linux カーネル リリース A A B B 検索クエリ: リリース OR カーネル ∪ Merge [B] [A] [A, B]

Slide 26

Slide 26 text

Search: マージは大変 © Recruit Co., Ltd., 2024. 26 転置 index Linux カーネル リリース A A B B 転置 Index の検索における Merge はコアであり、コストが超高い

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

転置 Index (Inverted Index) とは？ まぁ… ただの値がリストの ハッシュテーブルw © Recruit Co., Ltd., 2024. 28 転置 index Linux カーネル リリース A A B B

Slide 29

Slide 29 text

目標 • プリミティブな検索エンジンを作ってみよう • どのようなデータ構造を採用すればいいの？ • どんな実装をすれば良いの？ • 分散システムの良いところ・悪いところを、 作って理解しよう • 検索品質を改善してみよう • どんな方法がとれるの？ • そもそも品質って何？ © Recruit Co., Ltd., 2024. 29

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

２つの検索戦略 © Recruit Co., Ltd., 2024. 31 転置 index Linux カーネル リリース A A B B 1. TAAT = Term At A Time 2. DAAT = Document At A Time

Slide 32

Slide 32 text

２つの検索戦略 © Recruit Co., Ltd., 2024. 32 転置 index Linux カーネル リリース A A B B 1. TAAT = Term At A Time 2. DAAT = Document At A Time

Slide 33

Slide 33 text

TAAT (Term At A Time) における AND 検索 © Recruit Co., Ltd., 2024. 33 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 ① ② 1 1 1 2 3 3 4 5 5 6 6 7 1.「mmap」の posting list を accumulator に追加: acc０ = [1,5] 2.「Linux」の posting list か ら、次のルールで新しい accumulator acc 1 を作成: acc0 に有 ⇒ 追加 acc0 に無 ⇒ 無視 acc1 = [1, 5] 検索クエリ: Linux AND mmap 要素数の少ない Posting List から開始するのが効率的！！

Slide 34

Slide 34 text

TAAT (Term At A Time) における OR 検索 © Recruit Co., Ltd., 2024. 34 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 ① ② 1 1 1 2 3 3 4 5 5 6 6 7 1.「mmap」の posting list を accumulator に追加: acc０ = [1,5] 2.「Linux」の posting list を accumulator に追加: acc1 = [1, 3, 5, 6] 検索クエリ: Linux OR mmap 効率的な方法はない…

Slide 35

Slide 35 text

２つの検索戦略 © Recruit Co., Ltd., 2024. 35 転置 index Linux カーネル リリース A A B B 1. TAAT = Term At A Time 2. DAAT = Document At A Time

Slide 36

Slide 36 text

DAAT (Document At A Time) の基本 © Recruit Co., Ltd., 2024. 36 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 1 1 1 2 3 3 4 5 5 6 6 7 • TAAT は横串 • DAAT は縦串

Slide 37

Slide 37 text

DAAT (Document At A Time) における AND 検索 © Recruit Co., Ltd., 2024. 37 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 ① ② 1 1 1 2 3 3 4 5 5 6 6 7 • Term 毎にカーソルを準備 • 各カーソルを移動し、共通の ドキュメントを発見したら、 accumulator に追加 検索クエリ: Linux AND mmap acc = []

Slide 38

Slide 38 text

DAAT (Document At A Time) における AND 検索 © Recruit Co., Ltd., 2024. 38 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 ① ② 1 1 1 2 3 3 4 5 5 6 6 7 • Term 毎にカーソルを準備 • 各カーソルを移動し、共通の ドキュメントを発見したら、 accumulator に追加 検索クエリ: Linux AND mmap acc = [1]

Slide 39

Slide 39 text

DAAT (Document At A Time) における AND 検索 © Recruit Co., Ltd., 2024. 39 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 ① ② 1 1 1 2 3 3 4 5 5 6 6 7 • Term 毎にカーソルを準備 • 各カーソルを移動し、共通の ドキュメントを発見したら、 accumulator に追加 検索クエリ: Linux AND mmap acc = [1]

Slide 40

Slide 40 text

DAAT (Document At A Time) における AND 検索 © Recruit Co., Ltd., 2024. 40 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 ① ② 1 1 1 2 3 3 4 5 5 6 6 7 • Term 毎にカーソルを準備 • 各カーソルを移動し、共通の ドキュメントを発見したら、 accumulator に追加 検索クエリ: Linux AND mmap acc = [1, 5]

Slide 41

Slide 41 text

DAAT (Document At A Time) における OR 検索 © Recruit Co., Ltd., 2024. 41 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 ① ② 1 1 1 2 3 3 4 5 5 6 6 7 • Term 毎にカーソルを準備して、 全ての要素を重複なく追加 検索クエリ: Linux OR mmap 効率的な方法はない…

Slide 42

Slide 42 text

TAAT vs DAAT © Recruit Co., Ltd., 2024. 42 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 1 1 1 2 3 3 4 5 5 6 6 7 • メモリ使用量が多いのは TAAT • OR 検索では差異なし • かなりプリミティブな作り

Slide 43

Slide 43 text

TAAT vs DAAT © Recruit Co., Ltd., 2024. 43 50,241件 10,320件 30,483件 500,020件 UNIX BSD mmap kernel Linux 520件 1 1 1 2 3 3 4 5 5 6 6 7 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_s olr_8/slides/3325/Sch indlerLucene8Slides.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 44

Slide 44 text

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

Slide 45

Slide 45 text

実装することなんてあるの？ © Recruit Co., Ltd., 2024. 45 Java で実装された 検索ライブラリ Lucene 利用 利用 Solr 検索エンジン、全文検索 No… since 2010 since 2004 since 1999

Slide 46

Slide 46 text

Lucene © Recruit Co., Ltd., 2024. 46 • 転置インデックスを提供 • 検索の戦略は DAAT • 検索の非常にネイティブな機能のみ提供 • 様々な検索機能 Boolean Query、Range Query、Fuzzy Query • スコアリング機能 設計が非常に優秀な証ですね。 since 1999

Slide 47

Slide 47 text

Lucene がベースにしているアーキテクチャを知ろう！ © Recruit Co., Ltd., 2024. 47 Data Structure? Where and How?

Slide 48

Slide 48 text

Lucene がベースにしているアーキテクチャを知ろう！ © Recruit Co., Ltd., 2024. 48 Data Structure? Where and How?

Slide 49

Slide 49 text

一般的な index のデータ構造 © Recruit Co., Ltd., 2024. 49 • B木（B-tree） • B+木（B+-tree） • B*木（B*-tree） • Skip-List

Slide 50

Slide 50 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 50 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 53395 53395 ものすごく疎な部分がある

Slide 51

Slide 51 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 51 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 53395 53395 ものすごく疎な部分がある

Slide 52

Slide 52 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 52 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 53395 53395 ものすごく疎な部分がある 53,392回も比較する！?

Slide 53

Slide 53 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 53 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 183 291 291 53395 53395 53395 53395 53395 53395 特定の間隔でジャンプ（Skip） する冗長なリストをもつ

Slide 54

Slide 54 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 54 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 291 53395 53395 53395 53395 53395 53395

Slide 55

Slide 55 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 55 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 291 53395 53395 53395 53395 53395 53395

Slide 56

Slide 56 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 56 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 291 53395 53395 53395 53395 53395 53395

Slide 57

Slide 57 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 57 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 291 53395 53395 53395 53395 53395 53395

Slide 58

Slide 58 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 58 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 291 53395 53395 53395 53395 53395 53395

Slide 59

Slide 59 text

Posting List (Skip List) © Recruit Co., Ltd., 2024. 59 4,820,483件 93,832,732件 car book 0件 53,392件 1 3 3 183 291 291 53395 53395 53395 53395 53395 53395 見回る回数が少ない！！ ※ スキップの段数に依存 ※ スキップの間隔に依存

Slide 60

Slide 60 text

Lucene の Posting List (Skip List) © Recruit Co., Ltd., 2024. 60 https://github.com/apache/lucene/blob/main/lucene/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 の Posting List (Skip List) © Recruit Co., Ltd., 2024. 61 Apache Lucene - Index File Formats: https://lucene.apache.org/core/9_0_0/core/org/apache/lucene/codecs/lucen e90/package-summary.html#package.description

Slide 62

Slide 62 text

一般的な index のデータ構造 © Recruit Co., Ltd., 2024. 62 • B木（B-tree） • B+木（B+-tree） • B*木（B*-tree） • Skip-List

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

Lucene がベースにしているアーキテクチャを知ろう！ © Recruit Co., Ltd., 2024. 65 Data Structure? Where and How?

Slide 66

Slide 66 text

ブロックデバイス？メモリーの間違いでは？ © Recruit Co., Ltd., 2024. 66

Slide 67

Slide 67 text

無邪気にメモリーには置けない… © Recruit Co., Ltd., 2024. 67 揮発

Slide 68

Slide 68 text

他にもすることがある！Search のマージは大変 © Recruit Co., Ltd., 2024. 68 転置 index Linux カーネル リリース A A B B 転置 Index の検索における Merge はコアであり、コストが超高い ↓ Merge 分のメモリー

Slide 69

Slide 69 text

無邪気に考えた場合の問題点 © Recruit Co., Ltd., 2024. 69 • 揮発性 • メモリー使用の割当： • インデックス用 • マージ用 • Update 時の反映 • Load 時間（起動までの時間） • マルチタスク・マルチスレッド対応 • 巨大なインデックスへの対応 Practice で全部解決してみよう！

Slide 70

Slide 70 text

無邪気に考えた場合の問題点 © Recruit Co., Ltd., 2024. 70 • 揮発性 • メモリー使用の割当： • インデックス用 • マージ用 • Update 時の反映 • Load 時間（起動までの時間） • マルチタスク・マルチスレッド対応 • 巨大なインデックスへの対応 が提供してくれる コア機能

Slide 71

Slide 71 text

それではどうするのか？ © Recruit Co., Ltd., 2024. 71

Slide 72

Slide 72 text

Practice① © Recruit Co., Ltd., 2024. 72

Slide 73

Slide 73 text

Practice①: 課題のゴール © Recruit Co., Ltd., 2024. 73 • 転置インデックスの構造を作ってみよう • Indexing と Search のフェーズが分離されていることを体感しよう • 転置インデックス上での検索の動作原理を実装していみよう（AND と OR） • 永続的なインデックスの保存方法を知る（一旦、ファイルに保存してみよう） • メモリー上への配置は結構時間がかかることを体感しよう 課題のゴール

Slide 74

Slide 74 text

Practice①: 準備 © Recruit Co., Ltd., 2024. 74 • Docker はインストールされていますか？ • VSCode はインストールされていますか？ • VSCode の 拡張機能 Dev Containers はインストールされていますか？ Python の実行環境 課題の参考資料をダウンロード • search-practice-2024.tgz をダウンロード • かなり raw level な python のプログラム！

Slide 75

Slide 75 text

Practice①: 【課題】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 75 • 転置インデックスを実装して、AND と OR 検 索してみよう • 転置インデックスをファイルに保存できるよう にしよう • ２つのフェーズを実装 • インデックス作成フェーズ • 検索フェーズ • 検索の戦略は TAAT で OK • 2つのファイルで転置インデックスを実現 • Term を管理する Python 辞書ファイル: index_offset.dat • Posting List のファイル: index_posting_list.dat 課題 T:00000 T:00001 T:00002 T:FFFFF D:001 10〜50個のドキュメント D:024 D:001 D:001 D:099 D:032 D:033 D:055 〜 index_offset.dat index_posting_list.dat

Slide 76

Slide 76 text

Practice①: 【戦略】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 76 • index_offset.dat (Term を管理する Python 辞書ファイル) • 各 Term の Posting List が Posting List のファイルのどこに存在する か？！の Offset を格納 • index_posting_list.dat (Posting List のファイル) • 実際の Posting List を保存 ２つのファイル T:00000 T:00001 T:00002 T:FFFFF D:001 10〜50個のドキュメント D:024 D:001 D:001 D:099 D:032 D:033 D:055 〜 index_offset.dat index_posting_list.dat

Slide 77

Slide 77 text

Practice①: 【仕様】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 要求される仕様 • ファイルに保存できること • Term は擬似的に 0〜F の長さ 5 の全ての組合せ T:00000 〜 T:FFFFF で総数 1,048,576 = 16^5 • Document の ID は D:000 〜 D:100 をランダム に生成 • 各 Term は 10 個から 50 個のランダムな個数の ドキュメントをもつ T:00000 T:00001 T:00002 T:FFFFF D:001 10〜50個のドキュメント D:024 D:001 D:001 D:099 D:032 D:033 D:055 〜 16^5 index_offset.dat index_posting_list.dat

Slide 78

Slide 78 text

Practice①: 転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 【p0 の内容】 「ただの配列をもった辞書じゃないの？！」 ⇒ Yes!!!!! 「ただ、ファイルに保存するだけ？！」 ⇒ Yes!!!... なので、折角だから pickle を使ってみた ここから、一歩進んで（課題） 【p1 の内容】 • Posting List を分割して、 – ファイルの位置 (offset) を記録部分と、 – 実際の Posting List を普通のファイルにする

Slide 79

Slide 79 text

Practice①: 【資料】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 79 参考資料の解説① • 「課題が分からん！」という人 ⇒ p0 を見てね！ • p0 版は「python のオブジェクトをファイ ルに保存」版 ⇒ キーポイントは pickle !! • ゴールは「Posting List のファイルを普通 の文字列のファイル」にしてみること • 「Term に対応する Posting List がファイ ルのどこにあるか？」を記録している 「Python のオブジェクト」は「オブジェ クトをファイルに保存」で OK ⇒ pickle 版流用でOK T:00000 T:00001 T:00002 T:FFFFF D:001 10〜50個のドキュメント D:024 D:001 D:001 D:099 D:032 D:033 D:055 〜 index_offset.dat index_posting_list.dat 普通のファイル Python 辞書のファイル

Slide 80

Slide 80 text

Practice①: 【資料】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 80 参考資料の解説② • 楽するための課題共通ライブラリ • search_practice_2024/ • posting_list.py • search_tool.py • term.py • 課題の解説プログラム (全部 python版) • search_practice_2024/p0/ • index.py • search.py • 回答例！！ (まずは見ないで頑張ろう！) • search_practice_2024/p1/answer/ • index.py • search.py T:00000 T:00001 T:00002 T:FFFFF D:001 p0_index.dat（課題の解説用） 10〜50個のドキュメント D:024 D:001 D:001 D:099 D:032 D:033 D:055 〜 16^5

Slide 81

Slide 81 text

Practice①: 【資料】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 81 参考資料の解説③ • term.py • 課題の term を作ってくれるクラス • 引数で何個 term を作るか？指定 • 引数なしだと、16^5 個（開発時は少なめに指定しましょう） • フォーマットは T:00000〜T:FFFFF • posting_list.py • 課題の Posting List を作ってくれるクラス • 擬似的に各 term は 10〜50 個のドキュメントを保持 • ドキュメントのIDは D:000〜D:100 でランダム（ランダムの seed は term にしているのでみんな同じ） • search_tool.py • Posting List に対して、AND と OR 検索を提供するクラス • ものすごくはしょってあり、set を使って楽しています • TAAT を仮定しています

Slide 82

Slide 82 text

Practice①: 【資料】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 82 参考資料の解説④ • 課題解説プログラムの実行方法 (command というファイルに全部書いてあります！) # インデックス生成 (100万オーダーで生成するので結構時間がかかります) $ python3 -m search_practice.p0.index # 検索（検索対象は __main__ 以下の term で指定。50万回検索するのでちょっと時間がかかります） $ python3 -m search_practice.p0.search

Slide 83

Slide 83 text

Practice①: 【資料】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 83 参考資料の解説⑤ 作業時は、生成するサイズを小さくしましょう！！ （時間がかかるので…） Index の Term.create() の引数指定で 100 個等指定すれば OK （デフォルト値は 16^5）

Slide 84

Slide 84 text

Practice①: 【資料】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 84 参考資料の解説⑥ • 採用するデータ構造 (TSV 形式) T:000FF ¥t 00012 ¥t D:032 ¥t D:036 ¥t … ¥t D:093¥n Term 保持している ドキュメントの個数 ５桁の ドキュメント ID 改行コード ５桁の ドキュメント ID

Slide 85

Slide 85 text

Practice①: 転置インデックスを実装してみよう © Recruit Co., Ltd., 2023. 85 改めて課題を T:00000 T:00001 T:00002 T:FFFFF D:001 10〜50個のドキュメント D:024 D:001 D:001 D:099 D:032 D:033 D:055 〜 • p0 と同じ結果になる p1 を作ろう • index.py • search.py • Posting List を分割して、 • ファイルの位置 (offset) を記録部分と、 • 実際の Posting List を普通のファイル にする 16^5 index_offset.dat index_posting_list.dat 普通のファイル Python 辞書のファイル

Slide 86

Slide 86 text

Practice①: 【資料】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 86 • p1 配下に index.py と search.py を作ったら (command というファイルに全部書いてあります！) # インデックス生成 $ python3 -m search_practice.p1.index # 検索 $ python3 -m search_practice.p1.search

Slide 87

Slide 87 text

Practice①: 【参考】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 87 実装上のキーワード (ヒント！) • Python の辞書ファイルの保存は pickle を使おう • Posting List のファイルの読み書きは codecs を使うのが吉 (utf-8 にしよう！) • Posting List 自体は可変長ですが、中身は固定長で OK！ • Posting List の長さが、そのまま offset になるように出来ます！ • Posting List ファイル内の読込は file の seek で行先頭を見つけ出し、readline で OK！

Slide 88

Slide 88 text

Practice①: 【参考】転置インデックスを実装してみよう © Recruit Co., Ltd., 2024. 88 Python のプロファイラーや time コマンドでの比較 (command というファイルに全部書いてあります！) $ python -m cProfile -s cumtime -m search_practice.p1.answer.index $ python -m cProfile -s cumtime -m search_practice.p1.answer.search $ time python -m search_practice.p1.answer.index $ time python -m search_practice.p1.answer.search

Slide 89

Slide 89 text

Practice① © Recruit Co., Ltd., 2024. 89 • 転置インデックスの「作成フェーズ」と「検索フェーズ」 • Dic 版 (p0) に比べて File 版 (p1) が遅いことを実感できましたか？！ • Load に時間がかかる点も気になりましたか？！

Slide 90

Slide 90 text

無邪気に考えた場合の問題点 © Recruit Co., Ltd., 2024. 90 • 揮発性 ⇒ p0:◯, p1:◯ • メモリー使用の割当：⇒ p0:✗, p1:◯ • インデックス用 • マージ用 • Update 時の反映 ⇒ p0:△, p1:△ ※ 作れば良いだけ • Load 時間（起動までの時間）⇒ p0:✗, p1:◯ • マルチタスク・マルチスレッド対応 ⇒ p0:△, p1:△ ※ 作れば良いだけ • 巨大なインデックスへの対応 ⇒ p0:✗, p1:◯ p1 は検索が遅い！！！ ↓ 致命的…

Slide 91

Slide 91 text

Practice① © Recruit Co., Ltd., 2024. 91 最近の Mac (SSD を含め) は本当に速くなってしまって… 体感できましたかね？！

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

実際はどうなの？ © Recruit Co., Ltd., 2024. 93

Slide 94

Slide 94 text

Lucene がベースにしているアーキテクチャを知ろう！ © Recruit Co., Ltd., 2024. 94 Data Structure? Where and How?

Slide 95

Slide 95 text

mmap © Recruit Co., Ltd., 2024. 95

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

mmap © Recruit Co., Ltd., 2024. 97 0x00000 実メモリ 0x00000 プロセスA 実アドレス 0x00000 プロセスB 仮想アドレス 仮想アドレス ファイル

Slide 98

Slide 98 text

Elasticsearch の推奨設定 © Recruit Co., Ltd., 2024. 98 “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.” ※ Set the JVM heap size 【注意】Java の世界から逸脱している（Java のヒープ外でアロケートされてる）

Slide 99

Slide 99 text

Lucene の index 格納 © Recruit Co., Ltd., 2024. 99 org.apache.lucene.store（代表的な3種類） 1. SimpleFSDirectory.java • java.nio.ByteBuffer 2. NIOFSDirectory.java • java.nio.ByteBuffer 3. MMapDirectory.java • java.nio.MappedByteBuffer • https://lucene.apache.org/core/9_5_0/core/org/apache/lucene/store/package-summary.html

Slide 100

Slide 100 text

Indeed の独自実装: util-mmap © Recruit Co., Ltd., 2024. 100 MappedByteBuffer の既知の制約を克服: – 安全にアンマップできない – サイズが 2GB (int) を超えるファイルをマップできない – スレッドセーフではない • https://jp.engineering.indeedblog.com/blog/2015/02/util-mmap-でメモリマッピング/ • https://github.com/indeedeng/util/tree/main/mmap

Slide 101

Slide 101 text

おまけ: それでも Disk からデータは引き出す © Recruit Co., Ltd., 2024. 101 • 一番検索で良く使うのは検索結果 • ブロックサイズを意識して格納 • ディスクへのアクセスは猛烈に遅いが ディスクキャッシュは早い • トレードオフが十分ならば圧縮して格納する

Slide 102

Slide 102 text

おまけ: 圧縮のトレードオフ © Recruit Co., Ltd., 2024. 102 読み込み完了 100MB/s 5,000KB 50ms 25ms 30GB/s =30,720MB/s 2,500KB 50%圧縮 読み込み完了 15ms 10ms＝解凍 300倍位速い！

Slide 103

Slide 103 text

Luceneで利用できる圧縮方式 © Recruit Co., Ltd., 2024. 103 LZ4 (選択可能: DEFLATE, Zstandard 等) • Zstandard を利用したいPR (Facebook 製): https://github.com/apache/lucene/pull/439 • https://gigazine.net/news/20120824-dragonquest-backstage-cedec2012/ • 圧縮率は低いが、圧縮速度が速い • 色々なところで使われている: – OS: Linux, FreeBSD – Hadoop, Cassandra – Nintendo Switch – ドラゴンクエストXのセーブデータ

Slide 104

Slide 104 text

Practice② © Recruit Co., Ltd., 2024. 104

Slide 105

Slide 105 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2024. 105 • Posting List を mmap で実装し、共有できることを知ろう（共有メモリ） • Update して、他のプロセスからどう見えるか？知ろう 課題のゴール https://docs.python.org/ja/3/library/mmap.html

Slide 106

Slide 106 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2024. 106 要求される仕様 • 扱う index は Practice①と同じ ⇒ 作らなく大丈夫！！！ • Posting List を mmap で実装しよう ⇒ index.py は 読み込み と デストラクタ だけでOK • 簡単な http サーバーを立ち上げて、検索とupdate が出 来るようにしよう ⇒ FastAPI を使おう！（開発コンテナ内に install 済み） • update は Posting List の内容を入れ替えて見る（追加・ 削除はせず、入れ替え）だけで OK • 検索は • /and?term=T:AAAAA,T:BBBBBで AND 検索 • /or?term=T:AAAA,T:BBBBBで OR 検索 • Update は • /update?term=T:AAAAA &old=D:00023&new=D:00032 で D:00023 を D:00032 へ update • 複数プロセスを立ち上げて、それぞれ検索し、他のプロセ スが update した内容が反映されるのを確かめよう Index Process Process Process

Slide 107

Slide 107 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2024. 107 mmap FastAPI 参考ページ

Slide 108

Slide 108 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2024. 108 mmap • 普通のファイル操作と同じことが出来る ⇒ p1 での実装と同じ！！！ • 書き換え（update）は、始点から終点までの変換 ⇒ mmap_object[5:7] = ‘abc’ ※ 長さは一緒じゃないとダメ！！

Slide 109

Slide 109 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2024. 109 参考資料の解説① • p1/index.py と p1/search.py とかなり似通った作りになります。 • index_offset.dat と index_posting_lists.dat はこれまでと一緒！ • update 機能は別途切り出して p2/update.py 等を作成 • 新たに FastAPI のサーバーを作りますが、面倒ならば server.py をご参考に • p2/server.py で各リクエストに対して、以下が動くイメージ: • p2/index.py • p2/search.py • p2/update.py

Slide 110

Slide 110 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2023. 110 参考資料の解説② • 課題のゴールは以下の作成: 1. p2/index.py • インデックス作成自体は、不要になります (__main__ を作る必要なしです！) • Load だけ、出来れば良い • p1/index.py で作ったファイルで OK • index_offset.dat • index_posting_list.dat 2. p2/search.py 3. p2/update.py 4. p2/server.py

Slide 111

Slide 111 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2024. 111 参考資料の解説③ # サーバー立ち上げ（port 番号指定） $ ./fastapi run search_practice/p2/answer/server.py --port 9000 # サーバー停止 $（Ctrl-C） # ブラウザ • http://0.0.0.0:9000/and?term=T:FFFD7,T:FFFDD • http://0.0.0.0:9000/or?term=T:FFFD7,T:FFFDD • http://0.0.0.0:9000/update?term=T:FFFD7&old=D:087&new=D:088 実行方法 (command というファイルに全部書いてあります！)

Slide 112

Slide 112 text

Practice②: 転置インデックスを mmap で実装してみよう © Recruit Co., Ltd., 2024. 112 FastAPI で操作できるようになったら… # サーバーを複数立ち上げ $ fastapi run search_practice/p2/answer/server.py --port 9000 $ fastapi run search_practice/p2/answer/server.py --port 9001 $ fastapi run search_practice/p2/answer/server.py --port 9002 # あるサーバーから update を実行して、 # 他のサーバーでの検索結果 (サンプルでは AND 検索) が変化するのを確認

Slide 113

Slide 113 text

Practice② © Recruit Co., Ltd., 2024. 113 • Dic 版 (p0) と File 版 (p1) の欠点が解消されましたか？！ • プロセス間通信もできるので複数呼び出し可能になりましたか？！

Slide 114

Slide 114 text

無邪気に考えた場合の問題点 © Recruit Co., Ltd., 2024. 114 • 揮発性 ⇒ p0:◯, p1:◯, p2: ◯ • メモリー使用の割当：⇒ p0:✗, p1:◯, p2:◯ • インデックス用 • マージ用 • Update 時の反映 ⇒ p0:△, p1:△, p2:◯ • Load 時間（起動までの時間）⇒ p0:✗, p1:◯, p2:◯ • マルチタスク・マルチスレッド対応 ⇒ p0:△, p1:△ , p2:◯ • 巨大なインデックスへの対応 ⇒ p0:✗, p1:◯, p2:◯ p2 は検索が速い！ ↓ OK

Slide 115

Slide 115 text

Lucene がベースにしているアーキテクチャを知ろう！ © Recruit Co., Ltd., 2024. 115 Data Structure? Where and How?

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

「マルチプロセスというか、そもそも1台に置けないのですけど…」 © Recruit Co., Ltd., 2024. 117

Slide 118

Slide 118 text

Solr や Elasticsearch は何を提供してくれているの？ © Recruit Co., Ltd., 2024. 118 • RESTfull なAPIの提供 • 管理機能の提供 • クラスタリング機能を提供

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

50,241件 10,320件 520件 30,483件 500,020件 1. 同じキーが同じサーバーにいる必要がない ⇒ 「mmap」が別のサーバーにあっても良い【分散】 2. マージさえできればよい ⇒ 「mmap」が複数のサーバーにあってもよい【重複】 UNIX BSD mmap kernel Linux 分散検索 © Recruit Co., Ltd., 2024. 120

Slide 121

Slide 121 text

分散検索: indexing UNIX mmap Linux UNIX mmap Linux UNIX mmap Linux © Recruit Co., Ltd., 2024. 121

Slide 122

Slide 122 text

分散検索: 概念（Elasticsearch の用語にて） • 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ • シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング • どのシャードに格納するのかは、あなた次第！ © Recruit Co., Ltd., 2024. 122

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

• 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ • シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング • どのシャードに格納するのかは、あなた次第！ 分散検索: 可用性（Availability） 126 A Shard C Shard B Shard C Shard A Shard B Shard ✗ © Recruit Co., Ltd., 2024. ゆっくり寝るには、 とっても大事ですね

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

分散検索: Two Phase Search, query and fetch クエリー:（アイスクリーム AND すいか味）ORDER BY 安い順 LIMIT 3 OFFSET 100 138 Shard A アイスクリーム 20０円 5０円 850円 120円 Shard B アイスクリーム 320円 220円 10円 900円 Shard C アイスクリーム 850円 300円 500円 720円 © Recruit Co., Ltd., 2024. 【重要】もちろんキャッシュが使えて、最重要！

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

Practice③ © Recruit Co., Ltd., 2024. 140

Slide 141

Slide 141 text

Practice③: 分散検索を実装してみよう © Recruit Co., Ltd., 2024. 141 • 分散検索がどのように動くのか？ 理解しよう • 可用性を上げるにはどうしたらよい か？体験しよう • スケールすると（インデックスサイ ズが大きくなると）何が大変になる か？理解しよう 課題のゴール Index ① Request /and?term=AAAAA,BBBBB ② 分散検索 /get?term=AAAAA ③ local 検索 ③ local 検索 ② 分散検索 /get?term=BBBBB

Slide 142

Slide 142 text

Practice③: 分散検索を実装してみよう © Recruit Co., Ltd., 2024. 142 要求される仕様 • 扱う index は Practice②と同じ • 通信は http • 分散検索は • /and?term=AAAAA,BBBBBで AND 検 索 • /or?term=AAAA,BBBBBで OR 検索 • 単純に１個の term の Posting List を GET する API を追加（追加といっても /and と /or のどちらかを流用すれば OK） • /get?term=AAAA • マージ処理（実際の AND と OR の処理）は リクエストを受け取ったサーバーで OK Index ① Request /and?term=AAAAA,BBBBB ② 分散検索 /get?term=AAAAA ③ local 検索 ③ local 検索 ② 分散検索 /get?term=BBBBB

Slide 143

Slide 143 text

Practice③: 分散検索を実装してみよう © Recruit Co., Ltd., 2024. 143 参考資料の解説① • p2/server.py と p2/search.py を改造すれば OK • /_getは p2/server.py の AND 処理と OR 処理と同じ • NODE は固定で OK NODES = [ ‘0.0.0.0:9000’, ‘0.0.0.0:9001’, ‘0.0.0.0:9002’, ] ※ はじめは NODE を 1 個で試してみよう！ • and のリクエストを受け取ると、各 term 毎に Posting List を各サーバーに http で要求し、全ての結果をマージ（AND or OR）する • p2/search.py の変更点: • これまでの Posting List の取得を各サーバーに問い合わせて、取得するように変更 (http client が登場！！) • /get は自前で Posting List を取得 • p2/server.py の変更点: • /get を追加し、時前で Posting List を取得する method の呼び出しに変更

Slide 144

Slide 144 text

Practice③: 分散検索を実装してみよう © Recruit Co., Ltd., 2024. 144 参考資料の解説② 「直列にリクエスト投げるの、もったいなくない？！」 と言う方は鋭い！！ 是非、async で非同期に取得してみてください！！

Slide 145

Slide 145 text

Practice③: 分散検索を実装してみよう © Recruit Co., Ltd., 2024. 145 参考資料の解説② httpx がインストールされています！！！

Slide 146

Slide 146 text

Practice③: 分散検索を実装してみよう © Recruit Co., Ltd., 2024. 146 参考資料の解説② • キーワードは • httpx.AsyncClient • Client からの response は response object です！結果の json を取りたい時は response.json() だけで大丈夫！ • asyncio.gather • 非同期で複数リクエストを投げて、それを配列に格納して、その配列のそれぞれのレスポンス取得が終わるの gather で待ちます！

Slide 147

Slide 147 text

Practice③: 分散検索を実装してみよう © Recruit Co., Ltd., 2024. 147 # サーバーを複数立ち上げ (command というファイルに全部書いてあります！) $ ./fastapi run search_practice/p2/answer/server.py --port 9000 $ ./fastapi run search_practice/p2/answer/server.py --port 9001 $ ./fastapi run search_practice/p2/answer/server.py --port 9002 # あるサーバーから search を実行して、 # 各サーバーがリクエストを受け取り、 # これまでと結果が変わらないことを確認 # ブラウザ # and だとちょっと面白くないので、 # or でいっぱい term を足してみよう！ http://0.0.0.0:9000/or?term=T:FFFD7,T:FFFD D,T:00AABB,T:00CCBB,T:CCBBDD,T:FFFFFF,T:8 8FF11,T:66CC77

Slide 148

Slide 148 text

Practice③ © Recruit Co., Ltd., 2024. 148 • 分散処理を作れた感じがつかめましたか？ • Merge の処理がヘビーになる感じがつかめましたか？

Slide 149

Slide 149 text

分散検索: 概念（Elasticsearch の用語にて） • 各サーバーをノードと呼ぶ • 各ノードは複数のシャード（部分index）をもつ • シャードは以下を提供 • 可用性（Availability） • 負荷分散（Load Balance） • ドキュメント単位でルーティング • どのシャードに格納するのかは、あなた次第！ © Recruit Co., Ltd., 2024. 149 なんと！！ Elasticsearch の基本的な機能が出来ちゃったぞ！！

Slide 150

Slide 150 text

ちゃんと 話していないこと （出来ていないこと） © Recruit Co., Ltd., 2024. 150

Slide 151

Slide 151 text

Term （転置インデックスのキー） © Recruit Co., Ltd., 2024. 151

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

© Recruit Co., Ltd., 2024. 153 転置インデックス 50,241件 10,320件 30,483件 UNIX BSD mmap kernel Linux 520件 1 1 1 2 3 3 4 5 5 6 6 7 500,020件 T:00000 T:00001 T:00002 T:FFFFF 〜 MD5 or SHA-3 で出来なくもない！！

Slide 154

Slide 154 text

TokenStream = Term（＝ 文字列 ＋ フィールド）の stream ＋ アトリビュー ト • https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/index/Term.java • https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/analysis/TokenStream.java これはどう作るの？！ Lucene の世界では Tokenizer が分割をしてくれる！ © Recruit Co., Ltd., 2024. 154 Lucene の世界の Term と Token

Slide 155

Slide 155 text

• ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactoryPatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenizerFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory © Recruit Co., Ltd., 2024. 155 Lucene の Tokenizer

Slide 156

Slide 156 text

• ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactoryPatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenizerFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory © Recruit Co., Ltd., 2024. 156 Lucene の Tokenizer

Slide 157

Slide 157 text

• ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactoryPatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenizerFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory © Recruit Co., Ltd., 2024. 157 Lucene の Tokenizer

Slide 158

Slide 158 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.” © Recruit Co., Ltd., 2024. 158

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

• ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactoryPatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenizerFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory © Recruit Co., Ltd., 2024. 160 Lucene の Tokenizer

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

• ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactoryPatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenizerFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory © Recruit Co., Ltd., 2024. 163 Lucene の Tokenizer

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

Sudachi（形態素解析機） 最近は「sudachi」が人気 © Recruit Co., Ltd., 2024. 166 https://github.com/WorksApplications/Sudachi • A: 医薬/品/安全/管理/責任/者 • B：医薬品/安全/管理/責任者 • C：医薬品安全管理責任者

Slide 167

Slide 167 text

• ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactoryPatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenizerFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory © Recruit Co., Ltd., 2024. 167 Lucene の Tokenizer

Slide 168

Slide 168 text

Unicode のノーマライズ これは、検索に限らずどこでも使う！！ （一般的なプログラミング言語全てで提供。ICU、ありがとう！） • ＡＢＣ１２３ ⇒ ABC123 • ﾄｳｷｮｳ ⇒ トウキョウ • ㌀ ⇒ アパート • ㈱ ⇒ 株式会社 © Recruit Co., Ltd., 2024. 168 NFKC (Normalization Form KC)

Slide 169

Slide 169 text

• ClassicTokenizerFactory • EdgeNGramTokenizerFactory • HMMChineseTokenizerFactory • ICUTokenizerFactory • JapaneseTokenizerFactory • KeywordTokenizerFactory • LetterTokenizerFactory • LowerCaseTokenizerFactory • NGramTokenizerFactory • PathHierarchyTokenizerFactoryPatternTokenizerFactory • StandardTokenizerFactory • ThaiTokenizerFactory • UAX29URLEmailTokenizerFactory • UIMAAnnotationsTokenizerFactory • UIMATypeAwareAnnotationsTokenizerFactory • WhitespaceTokenizerFactory • WikipediaTokenizerFactory © Recruit Co., Ltd., 2024. 169 Lucene の Tokenizer 「京都」で「東京都」

Slide 170

Slide 170 text

© Recruit Co., Ltd., 2024. 170 Lucene の Tokenizer 「京都」 で 「東京都」

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

Precision and Recall © Recruit Co., Ltd., 2024. 172 適合率と再現率 理想と現実

Slide 173

Slide 173 text

Precision and Recall © Recruit Co., Ltd., 2024. 173 適合率と再現率 一般的な二値分類の評価一緒 パッーと流してOK

Slide 174

Slide 174 text

適合率と再現率 Precision and Recall 検索結果が 適合性：現実における理想の割合 再現性：理想における現実の割合 © Recruit Co., Ltd., 2024. 174

Slide 175

Slide 175 text

理想の検索結果 C 実際の検索結果 B A 再現率＝ C A 適合率＝ B A © Recruit Co., Ltd., 2024. 175 適合率と再現率

Slide 176

Slide 176 text

意味：どれほど正確か？＝正確性＝ノイズを含まない比率 実際の検索結果（B）に理想の結果（A）が含まれている割合 理想の検索結果 C 実際の検索結果 B A © Recruit Co., Ltd., 2024. 176 再現率＝ C A 適合率＝ B A 適合率

Slide 177

Slide 177 text

意味：どれほど網羅しているか？網羅性＝取りこぼしが少ない比率 理想の検索結果（C）の内、実際の検索結果として取得できた（A）割合 理想の検索結果 C 実際の検索結果 B A © Recruit Co., Ltd., 2024. 177 再現率＝ C A 適合率＝ B A 再現率

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

なんでも正しい1件しか返却しない！ ⇒ 最高 • 適合率を上げれば、再現率は下がり、、 • 再現率を上げれば、適合率が下がる。 理想の検索結果 C 実際の検索結果 B A © Recruit Co., Ltd., 2024. 179 再現率＝ C 1 ＝1 適合率＝ B A 極端な適合率

Slide 180

Slide 180 text

• 適合率を上げれば、再現率は下がり、 • 再現率を上げれば、適合率が下がる。 なんでも全件返却する！ ⇒ 最高 理想の検索結果 C A B 実際の検索結果 © Recruit Co., Ltd., 2024. 180 ＝1 再現率＝ C A 適合率＝ B A 極端な再現率

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

F-measure の値が大きければ、バランスのとれた良い結果 F-measure ＝ 適合率 （ 1 ＋ 再現率 1 ） 2 © Recruit Co., Ltd., 2024. 182 F-measure：適合率と再現率のバランス

Slide 183

Slide 183 text

ところで… © Recruit Co., Ltd., 2024. 183

Slide 184

Slide 184 text

理想の検索結果 C 実際の検索結果 B A © Recruit Co., Ltd., 2024. 184 実際の結果と理想の結果を全部？

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

そもそも、 検索結果を全件見る？！ © Recruit Co., Ltd., 2024. 186

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

ランキング © Recruit Co., Ltd., 2024. 188

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

なるべく多く検索結果に含めて、 結局ランキング © Recruit Co., Ltd., 2024. 190

Slide 191

Slide 191 text

{ "_score" : 656.68774, "_source" : { "nikki_kuromoji" : "雪の目黒", "nikki_ngram" : "雪の目黒“ } }, { "_score" : 23.361103, "_source" : { "nikki_kuromoji" : "雨の中目黒", "nikki_ngram" : "雨の中目黒“ } } © Recruit Co., Ltd., 2024. 191 「Elasticsearch は何か出しているよ？」

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

Okapi BM25: 1980年代から90年代に、ロンドン大学シティ校 で作られた Okapi 検索システムで実装されたから © Recruit Co., Ltd., 2024. 193

Slide 194

Slide 194 text

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

Slide 195

Slide 195 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 © Recruit Co., Ltd., 2024. 195

Slide 196

Slide 196 text

困ってる人：「文章が沢山あるのだけど、それぞれ の文章に特徴的なタグを付けられないかな？！」 © Recruit Co., Ltd., 2024. 196 私達：「OK！TF-IDF か Okapi BM25bを使えばタグ付け完了」

Slide 197

Slide 197 text

ちょっと脱線… © Recruit Co., Ltd., 2024. 197

Slide 198

Slide 198 text

© Recruit Co., Ltd., 2024. 198 【脱線】これまでの普通の検索は… 検索クエリー: たらこ＋1万円以上 ⇒ Document A Document B Document C ドキュメント を保存

Slide 199

Slide 199 text

© Recruit Co., Ltd., 2024. 199 【脱線】逆にすることができる！！！ 検索クエリー①: たらこ＋1万円以上 Document A 検索クエリー②: 辛子明太子＋20万円以上 検索クエリー③: 甘口明太子＋1000円以下 ⇒ クエリー を保存

Slide 200

Slide 200 text

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

Slide 201

Slide 201 text

TF-IDF © Recruit Co., Ltd., 2024. 201

Slide 202

Slide 202 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 の全体でのレア度） © Recruit Co., Ltd., 2024. 202

Slide 203

Slide 203 text

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

Slide 204

Slide 204 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 である © Recruit Co., Ltd., 2024. 204

Slide 205

Slide 205 text

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

Slide 206

Slide 206 text

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

Slide 207

Slide 207 text

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

Slide 208

Slide 208 text

Okapi BM25b © Recruit Co., Ltd., 2024. 208

Slide 209

Slide 209 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はどちらも一緒 © Recruit Co., Ltd., 2024. 209

Slide 210

Slide 210 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はどちらも一緒 © Recruit Co., Ltd., 2024. 210 単語数！ 14,352 ＞ 23

Slide 211

Slide 211 text

BM25の定義 ・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 © Recruit Co., Ltd., 2024. 211 Linux Linux（リナックス、 他の読みは後述）は、 UnixライクなOS カーネルである）。

Slide 212

Slide 212 text

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

Slide 213

Slide 213 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 はスコア大 © Recruit Co., Ltd., 2024. 213

Slide 214

Slide 214 text

困ってる人：「文章が沢山あるのだけど、それぞれ の文章に特徴的なタグを付けられないかな？！」 © Recruit Co., Ltd., 2024. 214 私達：「OK！TF-IDF か Okapi BM25bを使えばタグ付け完了」

Slide 215

Slide 215 text

そもそもTF-IDF を何故計算していたのか？ © Recruit Co., Ltd., 2024. 215

Slide 216

Slide 216 text

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

Slide 217

Slide 217 text

結局、ランキングでした… © Recruit Co., Ltd., 2024. 217

Slide 218

Slide 218 text

{ "_score" : 656.68774, "_source" : { "nikki_kuromoji" : "雪の目黒", "nikki_ngram" : "雪の目黒“ } }, { "_score" : 23.361103, "_source" : { "nikki_kuromoji" : "雨の中目黒", "nikki_ngram" : "雨の中目黒“ } } © Recruit Co., Ltd., 2024. 218 「Elasticsearch は何か出しているよ？」⇒ Okapi BM25b

Slide 219

Slide 219 text

めでたし、めでたし… © Recruit Co., Ltd., 2024. 219 本当に？！

Slide 220

Slide 220 text

© Recruit Co., Ltd., 2024. 220 Customer First と Client First は何処へ？

Slide 221

Slide 221 text

© Recruit Co., Ltd., 2024. 221 $ ￥ CVR や売上は何処へ？

Slide 222

Slide 222 text

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

Slide 223

Slide 223 text

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

Slide 224

Slide 224 text

nDCG の仲間達 • nDCG • Precision@k • mAP (Mean Average Precision) • MMR (Maximal Marginal Relevance) © Recruit Co., Ltd., 2024. 224

Slide 225

Slide 225 text

レコメンド © Recruit Co., Ltd., 2024. 225

Slide 226

Slide 226 text

広告 © Recruit Co., Ltd., 2024. 226 引用元: Google LLC https://www.google.com/

Slide 227

Slide 227 text

nDCG：実際の検索結果 ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 © Recruit Co., Ltd., 2024. 227 クエリー「からし明太子」

Slide 228

Slide 228 text

nDCG：実際のカスタマーの行動 クエリー「からし明太子」 ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 © Recruit Co., Ltd., 2024. 228

Slide 229

Slide 229 text

ちょっと脱線 「クリック」と「購入」って？ © Recruit Co., Ltd., 2024. 229

Slide 230

Slide 230 text

表示された クリックされた 購入された CTR と CVR © Recruit Co., Ltd., 2024. 230

Slide 231

Slide 231 text

表示された CTR と CVR PV (Page View): 表示された回数 © Recruit Co., Ltd., 2024. 231

Slide 232

Slide 232 text

表示された クリックされた CTR と CVR PV (Page View): 表示された回数 CTR = 表示された回数 クリックされた回数 (Click Through Rate) © Recruit Co., Ltd., 2024. 232

Slide 233

Slide 233 text

表示された クリックされた 購入された CTR と CVR PV (Page View): 表示された回数 CTR = 表示された回数 クリックされた回数 (Click Through Rate) CVR = 表示された回数 購入された回数 (Conversion Rate) ※何を Conversion と考えるか？はサービス次第 © Recruit Co., Ltd., 2024. 233

Slide 234

Slide 234 text

nDCG：実際のカスタマーの行動 クエリー「からし明太子」 ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 © Recruit Co., Ltd., 2024. 234

Slide 235

Slide 235 text

© Recruit Co., Ltd., 2024. 235 仮定: ランキング上位の方が conversion しやすい

Slide 236

Slide 236 text

© Recruit Co., Ltd., 2024. 236 理想と実際

Slide 237

Slide 237 text

nDCG：実際のカスタマーの行動 クエリー「からし明太子」 ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 2位なのに 頑張っている 4位なのに断トツ？！ 1位なのに普通かな ③と④は上下反転？！ © Recruit Co., Ltd., 2024. 237

Slide 238

Slide 238 text

nDCG：実際の結果 クエリー「からし明太子」 ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 © Recruit Co., Ltd., 2024. 238

Slide 239

Slide 239 text

nDCG：理想の結果 クエリー「からし明太子」 ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 © Recruit Co., Ltd., 2024. 239

Slide 240

Slide 240 text

nDCG：理想の結果 クエリー「からし明太子」 ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 元々1位だったアド バンテージを考慮 していない © Recruit Co., Ltd., 2024. 240

Slide 241

Slide 241 text

nDCG は 順位のアドバンテージ を考慮した評価 © Recruit Co., Ltd., 2024. 241

Slide 242

Slide 242 text

nDCG：スコア ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 S1=150 S2=110 S3=45 S5=60 S4=250 1. 各順位の結果はスコアをもっている （例: クリック数＋購入数×100） © Recruit Co., Ltd., 2024. 242

Slide 243

Slide 243 text

nDCG：Top 5 のスコア ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 S1=150 S2=110 S3=45 S5=60 S4=250 2. 各順位に応じて、ペナルティ を与え、全体のスコアを計算 DCG5＝ S1 + + + … log2 S2 log3 S3 © Recruit Co., Ltd., 2024. 243

Slide 244

Slide 244 text

nDCG：理想の結果のDCG=iDCG (ideal DCG) ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 3. スコア順の DCG を求める ＝ iDCG ⇒ DCG が MAX DCG5＝ S4 + + + … log2 S1 log3 S2 S4=250 S1=150 S2=110 S3=45 S5=60 © Recruit Co., Ltd., 2024. 244

Slide 245

Slide 245 text

nDCG = iDCG（理想のDCG） DCG（現実のDCG） © Recruit Co., Ltd., 2024. 245

Slide 246

Slide 246 text

nDCG = 518.78 439.23 = 0.84 理想の結果の84% © Recruit Co., Ltd., 2024. 246

Slide 247

Slide 247 text

nDCG：ちょっと改善してみる ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 © Recruit Co., Ltd., 2024. 247

Slide 248

Slide 248 text

nDCG：ちょっと改善してみる ① 辛子明太子 ゴールデンサイズ ② 明太子！【送料無料】てんこ盛り ③ からし明太子高菜80g×2パック ④【送料無料】極上 辛子明太子 1kg ⑤ パスタソース 逸品 からし明太子 クリック 購入 クリック 購入 クリック 購入 クリック 購入 クリック 購入 © Recruit Co., Ltd., 2024. 248

Slide 249

Slide 249 text

nDCG = 518.78 489.23 = 0.94 © Recruit Co., Ltd., 2024. 249 理想の結果の94%

Slide 250

Slide 250 text

ランキングの良さを 定量的に評価 できるようになりました。 © Recruit Co., Ltd., 2024. 250

Slide 251

Slide 251 text

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

Slide 252

Slide 252 text

「あれ？…何かおかしいぞ… スコアが出せるならば、 そのスコア順がランキングでいいのでは？」 © Recruit Co., Ltd., 2024. 252

Slide 253

Slide 253 text

あなたは 100%MAXパーフェクト に正しい！！ © Recruit Co., Ltd., 2024. 253

Slide 254

Slide 254 text

実際の改善では？ • 「ドキュメントは新しい方が良さそうだ」 ⇒ 登録日時を考慮 • 「このクエリーのときにはこういう価格帯が良さそうだ」 ⇒ 価格帯を考慮 • 「あまり見られていなドキュメントにも可能性があるのでは？」 ⇒ 公平性を考慮 • 「ユーザーの評価も含めるべきではないか？」 ⇒ ユーザー評価を考慮 © Recruit Co., Ltd., 2024. 254 既成概念や過去の成功体験はありまり役荷立たない ⇒ A/B テストの繰り返し

Slide 255

Slide 255 text

注意点！！ • 「ドキュメントは新しい方が良さそうだ」 ⇒ 登録日時を考慮 • 「このクエリーのときにはこういう価格帯が良さそうだ」 ⇒ 価格帯を考慮 • 「あまり見られていなドキュメントにも可能性があるのでは？」 ⇒ 公平性を考慮 • 「ユーザーの評価も含めるべきではないか？」 ⇒ ユーザー評価を考慮 © Recruit Co., Ltd., 2024. 255 既存のスコアを計算できないケースに注意！！

Slide 256

Slide 256 text

© Recruit Co., Ltd., 2024. 256 現実的で実際的な検索結果の評価 • メジャークエリー（ロングテールだったとしても…）の nDCG • 積分して全体の7割でもカバー出来れば大捕物 • 悪いクエリーのカテゴライズ • 例 • 新規ドキュメントの比重 (十分インプレッションされているか？) • 特定の内容に偏りがないか (あるドメインばかりの結果で埋め尽くされる) • 地域系のクエリーが悪い (例: 東京、大阪) • 特定の属性に関するクエリーが悪い (例: 色、規格)

Slide 257

Slide 257 text

それでは、どのようなスコアリングの要 素があるのか！？ 更に、一般的な(=万能な)スコアリング の要素があるのか？！ © Recruit Co., Ltd., 2024. 257

Slide 258

Slide 258 text

実際の改善では？ • 「ドキュメントは新しい方が良さそうだ」 ⇒ 登録日時を考慮 • 「このクエリーのときにはこういう価格帯が良さそうだ」 ⇒ 価格帯を考慮 • 「あまり見られていなドキュメントにも可能性があるのでは？」 ⇒ 公平性を考慮 • 「ユーザーの評価も含めるべきではないか？」 ⇒ ユーザー評価を考慮 © Recruit Co., Ltd., 2024. 258 既成概念や過去の成功体験はありまり役荷立たない ⇒ A/B テストの繰り返し

Slide 259

Slide 259 text

∞ の可能性 © Recruit Co., Ltd., 2024. 259

Slide 260

Slide 260 text

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

Slide 261

Slide 261 text

∞ の可能性！！ © Recruit Co., Ltd., 2024. 261

Slide 262

Slide 262 text

アジェンダ • 検索とは何か？ • 転置インデックスとは何か？ • 転置インデックスを実装するには？ • 分散検索とは何か？ • Term とは何か？ • 良い検索結果とは何か？ • 検索結果のスコアとは何か？ • 良いランキングとは何か？ • 良いランキングを作るとは何か？ • おまけ: RAG © Recruit Co., Ltd., 2024. 262

Slide 263

Slide 263 text

RAG とは？ • RAG (Retrieval Augmented Generation) ⇒ 日本語では「検索拡張生成」 • 一体何を拡張するの？ ⇒「検索拡張生成（RAG）とは、テキスト生成をプライベートデータソースまたは 独自のデータソースからの情報で補完する技術のことです。 」（検索拡張生成 （RAG）とは？ ） • 何に使うの？！ ⇒ 質問に対する回答、コンテンツを生成、セマンティクス検索 例: クエリー「はんだ付けの手順」※ 文字列検索ではない！ • 何でそんなにもてはやされているの？！ ⇒ 新規の学習をするのではなく（例: 社内情報=社員以外不要、最新情報、そもそも 学習していない情報）、検索結果を生成AIに渡し、回答を生成させる © Recruit Co., Ltd., 2024. 263

Slide 264

Slide 264 text

LLM (Large Language Model) の問題点を RAG が解決する？！ • LLM の問題点とは？！ ⇒ 幻覚（ハルシネーション）を引き起こす ⇒ 知識更新が遅い ⇒ 回答の透明性の欠如 • 幻覚（ハルシネーション= hallucinations） とは？ ⇒ AI が勝手に回答を作りだす • 知識更新が遅い（slow knowledge updates）？！ ⇒ そもそも、学習していない • 回答の透明性の欠如 (lack of transparency)？！ ⇒「ほんまかいな？！」の検証 © Recruit Co., Ltd., 2024. 264

Slide 265

Slide 265 text

© Recruit Co., Ltd., 2024. 265 RAG：より良い参考ページ • Elastic: • 検索拡張生成（RAG）とは？ • Amazon (AWS): • RAG とは何ですか? • Google (Google Cloud): • Your RAGs powered by Google Search technology, part 1 • Your RAGs powered by Google Search technology, part 2 • Arxiv.org: • Retrieval-Augmented Generation for Large Language Models: A Survey

Slide 266

Slide 266 text

© Recruit Co., Ltd., 2024. 266 RAG のコア • Retriever ⇒ 関連する情報の取得 (検索: LLM に供給するデータの精度) • Generator ⇒ Retriever から受け取ったデータから、自然で流暢な自然文を生成 • Augmentation ⇒ 統合：Retriever と Generator の情報を統合

Slide 267

Slide 267 text

∞ の可能性！！ © Recruit Co., Ltd., 2024. 267

Slide 268

Slide 268 text

Fin お疲れ様でした。 © Recruit Co., Ltd., 2024. 268