Ask! NIKKEI RAG検索技術の深層

Slide 1

Slide 1 text

Ask! NIKKEI RAG 検索技術の深層舘野祐一 / @hotchpotch / id:secondlife 2025 年02 月06 日 - 日経電子版開発と記事検索の最前線

Slide 2

Slide 2 text

※ 資料中のリンクは、PDF をダウンロードするとクリック出来ます

Slide 3

Slide 3 text

自己紹介舘野祐一, セコン, @hotchpotch https://secon.dev/ ソフトウェアエンジニア一人法人の代表 Ask! NIKKEI プロダクトマネージャ情報検索エンジニア情報検索関連のオープンな活動 JQaRA: 検索拡張(RAG) 評価のための日本語 Q&A データセット JaCWIR: 日本語情報検索評価のための小規模でカジュアルなWeb タイトルと概要のデータセット日本語最高性能のReranker をリリース / そもそも Reranker とは? 情報検索モデルで最高性能(512 トークン以下) ・日本語版SPLADE v2 をリリース 100 倍速で実用的な文章ベクトルを作れる、日本語 StaticEmbedding モデルを公開

Slide 4

Slide 4 text

Ask! NIKKEI とは? 「広く知る。深く知る。」新しいニュース体験 Ask! NIKKEI は、記事を読んでいて疑問が生じた瞬間に、日経電子版の記事からAI がわかりやすく回答するサービスです。キーワードや背景知識の補足から専門的な深堀りまで、「読む・疑問・解決」をその場で実現し、読者に「広く知る」「深く知る」新しいニュース体験を提供します。 ( 現在・一部ユーザを対象にベータ公開中)

Slide 5

Slide 5 text

RAG （Retrieval Augmented Generation ）とは RAG （Retrieval Augmented Generation ）とは、LLM （大規模言語モデル）などの生成系AI に外部データベースを組み合わせ、より正確かつ豊富な回答を導く仕組み。「Retrieval （検索）」と「Generation （生成）」の組み合わせ必要情報を検索し、その情報をもとに回答を生成する二段構えで、最新情報や専門性を補強。誤情報リスクの軽減と透明性信頼性の高い情報ソースに限定して検索し、参照元を提示できるため、回答の正確性と信頼度を高められる。つまり… 👉日経電子版とは相性が良いですね！

Slide 6

Slide 6 text

RAG で求められる情報検索システム検索結果を活用するのは LLM クエリーに対して「LLM の生成結果が」有益になる記事を返す人間よりも、AI に最適な結果速度も、ある程度速い方が良い AI Agent などは、何度も検索をして熟考する人間ならたくさん検索は億劫( ≒高コスト) だが、AI なら低コスト

Slide 7

Slide 7 text

今回作った情報検索システムの流れ

Slide 8

Slide 8 text

今回作った情報検索システムの流れ検索前処理検索する前(pre) の処理クエリー展開検索1st: 記事全てを対象に、関連のある記事を取得検索2nd: 1st で絞り込んだ記事から、さらにフィルタリング・並べ替え

Slide 9

Slide 9 text

検索前処理

Slide 10

Slide 10 text

クエリー展開入力文を、検索に適したものに展開クエリ例: 🗣" 直近一年間の内容で、Android とiOS の良いこと悪いところを比較してまとめて。出力には比較の表を入れること。"

Slide 11

Slide 11 text

クエリ展開・検索時のオプションを抽出 🗣" 直近一年間の内容で、Android とiOS の良いこと悪いところを比較してまとめて。出力には比較の表を入れること。" " 直近一年間の内容で" これはクエリの中での条件文条件文から検索時に必要なオプションを抽出検索オプションの抽出現在が2025 年2 月6 日なら: 👉 start_date: 2024年2月6日

Slide 12

Slide 12 text

クエリ展開・本質的な質問文を作成 🗣" 直近一年間の内容で、Android とiOS の良いこと悪いところを比較してまとめて。出力には比較の表を入れること。" 「比較してまとめて」「出力には比較の表を入れること」などは、LLM がまとめる際に期待する指示これらを取り除いたり要約して、ユーザが望む本質的な質問文を作成本質的な質問 👉 AndroidとiOSの良いところ悪いところを知りたい

Slide 13

Slide 13 text

クエリ展開・クエリを複数に分ける 👉 AndroidとiOSの良いところ悪いところを知りたい本質的な質問では引っかかりにくいものを、複数( サブクエリ) に分ける本質的な質問を分解することで、多様なドキュメントを取得可能にサブクエリ展開例 Androidの良いところは？ iOSの良いところは？ Android の悪いところは？ iOSの悪いところは？

Slide 14

Slide 14 text

クエリ展開まとめ検索条件抽出: 検索時のオプション( 時刻指定など) の抽出本質的な質問文を作成: 入力から、本当に質問したいことは何か、を作成サブクエリ展開: 本質的な質問を分解することで、多様なドキュメントを取得実現方法今はルールベース+LLM でクエリ展開クエリ展開は、アプリケーションor 検索システム側、どちら側がやっても良い今はオプションでオンor オフが可能にアプリケーション側なら、さらにUX を加味したクエリ展開が可能直前に読んだ記事は何か、ユーザの興味関心は、等々の考慮

Slide 15

Slide 15 text

検索1st, 2nd の前に…

Slide 16

Slide 16 text

日経小型エンコーダモデルの作成 👉 このモデルを使った下流タスクが各々で登場 👉 基盤となるモデルを作ることで、他のタスクに応用

Slide 17

Slide 17 text

日経小型エンコーダモデルの作成日経電子版記事で学習した小型のエンコーダモデルを作成エンコーダ BERT など LLM に比べると、パラメータが小さい文章全体の特徴理解に強いデコーダ LLM などパラメータが基本大きい次の1 文字を予想・文章生成に強い

Slide 18

Slide 18 text

「小型」モデル？ Transformer 層のレイヤーパラメータ bert-base のレイヤーパラメータは 86M LLM はとても小さくても、500M 弱( 例:qwen2.5-0.5B) 今回作成したモデル 👉 わずか11M 小さいメリット学習が速い低GPU リソースで学習可能 / トライ& エラーがしやすく、試行回数を増やせる推論が速い 11M ならbert-base の約8 倍速で推論可能 / リアルタイム環境で高速に実行可能 👉レイテンシが重要な検索では価値が高い

Slide 19

Slide 19 text

日経トークナイザーの作成モデル作成の前準備日経の記事を中心に sentencepiece + unigram で学習したトークナイザー例: " インバウンドの成功事例は?" 日本語BERT: イン , バウ , #ンド , の , 成功 , 事例 , は , ? 日経トークナイザー: インバウンド , の , 成功 , 事例 , は , ? 日経電子版の頻出語彙は1 トークンに

Slide 20

Slide 20 text

日経小型エンコーダモデル - " 日経xsmall" の作成(1) Microsoft の mMiniLM-v2-L6-H384 をベースにファインチューン mMiniLM-v2-L6-H384: 👉マルチリンガル小型蒸留モデル大元は meta の xlm-roberta-large 日経トークナイザに差し替えて、単語 embeddings をマージロンドン: mMiniLM では" ロ", " ン", " ド", " ン" にトークナイズされる日経トークナイザでは「ロンドン」なので、単純に" ロ", " ン", " ド", " ン" の embeddings の平均で " ロンドン" にマージ具体的なやり方 XLMRobertaTokenizer を日本語で学習させて動かす - 既存の学習済みマルチリンガルモデルの tokenizer を、日本語のものへ差し替えたい

Slide 21

Slide 21 text

日経小型エンコーダモデル - " 日経xsmall" の作成(2) 日経電子版 + wikipedia の文章を元に、mMiniLM-v2-L6-H384 をファインチューンファインチューンはRetroMAE で RetroMAE: Pre-Training Retrieval-oriented Language Models Via Masked Auto-Encoder / MLM を、より検索系タスクで性能が出るようにする、教師なし学習手法 MAE = "Masked Auto-Encoder" 実際にRetroMAE を使うと、検索タスクで性能が向上日本語 BERT RetroMAE モデルの公開と、後続検索タスクでの評価データソースは日経電子版に加え、wikipedia も学習することで、汎化性能もあげるレイヤパラメータ11M の日経xsmall モデルの学習完了学習時間はGPU NVIDIA A100 で1 日かからなかった( ハズ)

Slide 22

Slide 22 text

検索1st: 記事全体から、関連のある記事を取得

Slide 23

Slide 23 text

検索1st: 記事全体から、関連のある記事を取得記事データから、質問に関連する記事を取得大量の記事から、関連する top-N 個をハイブリット検索で取得ハイブリット検索: 👉 異なる検索結果をまとめ合わせる手法よくあるハイブリット検索例: 1. transformer 検索用モデルを使った、文章全体の文脈を考慮した密ベクトル検索 👉 文脈に強い 2. BM25 を使った、単語の出現頻度ベースの疎ベクトル検索 👉 単語( キーワード) に強い 1. 2. では検索結果に方向性の違いが出るため、両方をマージした検索結果を使うことで、より良質な結果に

Slide 24

Slide 24 text

Ask! NIKKEI でのハイブリット検索 👉以下の組み合わせ結果を利用文脈を重視した密ベクトル検索汎化性能が高い高性能モデルを選択今は BAAI/bge-m3 の密ベクトルを利用キーワードを重視した疎ベクトル検索日経電子版ドメインに特化した検索モデルを独自に作成後ほど出てくる👉日経SPLADE モデル

Slide 25

Slide 25 text

記事検索用データセットの作成 🤔 なぜデータセットを作るの? 👉 検索評価や検索モデル作成には、データセットが必要記事を文脈と文章長で分割し、1~10 前後のチャンク( 部分テキスト) に今回は約100 万件のチャンクを作成それに紐づく、クエリ（質問文）を合成データセットとして作成学習・検索評価用にハードネガティブサンプリングもハードネガティブ≒正解のチャンクに似ているが正解ではないデータこのデータを学習することで「似ているけど違う」判定力が身に付く

Slide 26

Slide 26 text

合成データセットとは? 検索の学習・評価には、クエリ( 質問文) と正解文( チャンク) 、二つのペアが最低必要チャンクはあるので、質問をLLM に作らせる 👉合成データセット同一記事では別チャンクだったとしても、同じ質問文をLLM が作りがち複数チャンクから一括してクエリを作ることで、被りを抑える

Slide 27

Slide 27 text

日経SPLADE モデルの作成 SPLADE は、キーワード( 単語トークン) 特徴に強い、ニューラルネットワークの情報検索モデル情報検索モデルで最高性能(512 トークン以下) ・日本語版SPLADE v2 をリリース BM25 は基本完全一致例: 「訪日外国人が好みな料理」を検索 SPLADE なら「インバウンドで人気の食べ物」と書いてある記事もヒット( しやすい) BM25 はヒットしない密ベクトルモデルでもヒットするが、SPLADE はよりキーワードに強い日経xsmall と記事検索用データセット + オープンな公開データセットを元にモデル学習日経トークナイザは、日経の頻出単語で分割＝SPLADE と相性が良いイン , バウ , #ンドではなくインバウンド 👉日経SPLADE の完成 ( 学習時間は約24 時間)

Slide 28

Slide 28 text

日経SPLADE 性能評価・汎化性能 JMTEB: Japanese Massive Text Embedding Benchmark の検索タスクでの評価日経SPLADE はパラメータサイズが小さいが、全体的に高性能 mE5-large 並みの性能レイヤパラメータは1/30 ほどなので、単純計算では約30 倍高速チャンク分割しているデータでは、 Avg<512 ( テキストの長さが512 トークン以下) が重要 JMTEB Retrieval Model Name Avg Avg<512 Params nikkei_splade 0.7436 0.6878 11M OpenAI/text- embedding-3-large 0.7448 0.6301 不明 multilingual-e5- large 0.7098 0.6685 303M multilingual-e5- small 0.6727 0.6135 21M ※なお、PARAMS はTRANSFORMER 層のレイヤパラメータサイズを記載

Slide 29

Slide 29 text

日経SPLADE 性能評価・ドメイン特化性能記事データセットのtest セットに対しての評価日経電子版の記事で学習しているため、電子版記事なら圧倒的高評価 Model Name nDCG@10 Params nikkei_splade 0.868 11M bge-m3(dense) 0.7735 303M multilingual-e5-large 0.757 303M bm25 0.7359 None multilingual-e5-small 0.7164 21M

Slide 30

Slide 30 text

ハイブリット検索時の性能実際の検索クエリのスコアで評価 Top-10 の関連性スコアの平均で算出関連性スコア＝これから出てくる2nd フェイズ適用後の評価ハイブリッド検索 >> bge-m3 単体検索 ≒ 日経SPLADE 単体検索ハイブリットが一番良質なスコアに ( 全体的なロジックを日々変えているので、ざっくりとした評価)

Slide 31

Slide 31 text

検索1st: Ask! NIKKEI でのハイブリット検索まとめ文脈を重視した密ベクトル検索汎化性能が高い高性能マルチリンガルモデルを利用今は BAAI/bge-m3 の密ベクトルを利用キーワードを重視した疎ベクトル検索日経電子版ドメインに特化した検索モデルを作成作成した、小型の日経SPLADE モデルを活用 👉二つの組み合わせ結果を利用することで、より良い結果スコアに

Slide 32

Slide 32 text

検索2nd: さらに並べ替え・フィルタリング

Slide 33

Slide 33 text

検索2nd: さらに並べ替え・フィルタリング 1st ( ハイブリッド検索) で記事全体から、ある程度絞り込み 2nd では、さらに並び替えとフィルタリング 0.0~1.0 の関連性スコアを付与並び替え: 関連性順にソートフィルタリング: 関連性がないデータを削除

Slide 34

Slide 34 text

検索2nd: 日経Judge モデルの作成最適な検索結果は「LLM の視点から有益だ」と判定される文章検索を利用するのはLLM LLM as a Judge LLM が検索結果を評価するこの結果を直接学習させたもの 👉 日経Judge モデル

Slide 35

Slide 35 text

Reranker モデルの作成・学習 Judge モデルの学習前に… 日経 xsmall モデルをファインチューン検索1st で作った記事検索学習用データセット100 万件や、公開データセットをもとに、Reranker を学習 👉 日経 Reranker の完成 ( 学習は約12 時間) Reranker って？質問文とドキュメントを1 つのコンテキストで評価毎度計算が必要でコストが高いが、その分より良い検索結果を判定可能日本語最高性能のReranker をリリース / そもそも Reranker とは?

Slide 36

Slide 36 text

Reranker って？

Slide 37

Slide 37 text

日経 Reranker の評価記事データセットのtest セットに対しての評価 reranker はあらかじめ検索した Top-100 をさらに rerank しての評価 nikkei_splade よりも、さらに電子版ドメインに強い Model Name nDCG@10 Params nikkei_reranker 0.9 11M nikkei_splade 0.868 11M japanese-reranker-cross- encoder-large-v1 0.8351 303M bge-m3(dense) 0.7735 303M multilingual-e5-large 0.757 303M bm25 0.7359 None multilingual-e5-small 0.7164 21M

Slide 38

Slide 38 text

Judge 用データセットの作成欲しい結果は「LLM の視点から有益だ」と判定される文章検索を利用するのはLLM 1st の記事検索+ 日経Reranker でrerank( ソート) した結果Top-10 を元にLLM でスコア付 2: 質問の回答にズバリ役立つ文章 1: 質問の回答の補助に参考になる文章 0: 全く不要な文章様々な傾向の16 万件の質問と、 1st検索 + rerank top-10 の160 万件のスコアで学習

Slide 39

Slide 39 text

Judge スコアのイメージ LLM が、回答生成時に有益そうかの指示プロンプトでスコア付 1st 検索 + 日経Reranker で上位でも、LLM でスコア付すると低い場合も ※なお上記はイメージで、実際の結果ではありません

Slide 40

Slide 40 text

Judge モデルの学習日経Reranker モデルを、Judge データセットを元に、さらにファインチューン 0.0~1.0 へとスコアを変換スコア2: 有益 → スコア 1.0 スコア1 : 間接的に有益 → スコア 0.8 スコア0 : 有益でない → スコア 0.0 有益or 有益でない、を強く分けたいため、スコア1( 間接的に有益) は0.8 にマッピング Reranker とほぼ同じように学習 👉日経Judge モデルの完成 ( 学習は約2 時間) 関連性スコアとして利用

Slide 41

Slide 41 text

👉 Judge モデルとは、LLM の有益性判定スコアを学習したモデル ☑️ Reranker は、従来のクエリと文章の関連度を学習 ☑️ Judge は"LLM にとって有益な結果" を学習・0.0~1.0 でスコアリング ☑️ 有益でない結果は、フィルタで除外可能

Slide 42

Slide 42 text

フィルタリングでの活用 1st stage の検索結果では、スコアによるフィルタリングが難しいコサイン類似度が0.5 は関連性が高いの？低いの？🤔 →場合による。関連性がかなり高いこともあれば、かなり低いこともある閾値でのフィルタが難しい Judge モデルの場合 1.0 はLLM によって有益、0.0 は有益でないように学習されているスコアに一貫性があるので、スコアブーストをかけれる例えば、時刻が過去の記事ほどスコアを下げる、などを行なっている検索結果のスコア分布から、ざっくりフィルターの閾値が設定可能 👉ほぼ関係ない記事データをフィルタリングできる LLM でのハルシネーションの低下・入力トークンの削減に

Slide 43

Slide 43 text

Reranker, Judge の分布 Reranker は 1 or 0 で学習しているのでパキッと Judge は 0, 0.8, 1 で学習している・データセットのスコア分布も異なるので滑らかフィルタの閾値は、F2 スコアを中心に値を決める F2 スコアを使ったのは、関連情報の見逃しを最小限にしつつ、不要な情報を排除するため F2 はRecall( 関連情報をいかに漏らさず取得できるか) を優先しつつ、Precision( 取得した情報がいかに関連性が高いか) も考慮できるため、最適なバランスを検討できる

Slide 44

Slide 44 text

フィルタリング活用例「舘野重化学工業の今期の業績は？」そもそも、そんな会社がない・検索対象データベースには無い検索1st では「どこかの重化学工業会社の今期業績」の結果を取ってくる Judge スコアを使ってフィルターすると、関連性がないのでフィルターされ、ほぼヒットしない LLM が検索結果を元に生成せずとも「有益な検索結果がなかった」ことで処理分けが可能 LLM を使わずに「有益な情報がなかった」と即表示したり例えば、有益な結果がなければ、クエリを変えて再検索なども可能 AI エージェントで、AI 自身が様々な処理を再起的に行う時に「そもそもデータがない」を理解できるので役立つ " 舘野重化学工業の今期の業績は？" LLM が処理する前に、結果がなかったことが表示される（はず）

Slide 45

Slide 45 text

Reranker / Judge の速度と、小さなモデルの重要性 Reranker やJudge は、実は GPU をかなり使う処理検索結果200 件を処理するなら、ざっくり 200 * 400 トークン ≒ 80,000 トークンの処理が毎回必要この処理が小さな "11M" のモデルなら、100ms 以下で処理可能(GPU NVIDIA L4 の場合) " 小さな" ことで、そもそもの推論が速い推論サーバに rust で書かれ FlashAttention が使える text-embeddings-inference を利用 Python で処理するより、二倍以上速い (FA 速い!) 👉 リアルタイム検索システムに組み込んでも、現実的な時間で処理が可能に

Slide 46

Slide 46 text

検索速度は結構重要 AI や Agent と検索の相性の良さ多様な視点でたくさん調べるコストが低いしかし「検索時間」が長ければ、応答性はどんどん悪くなるできる限り最良の結果を、できる限り短い時間で提供する今回の検索システムでは、クエリ展開無しなら400ms, クエリ展開ありなら2000ms 弱で(LLM の処理が 1500ms…) の処理速度 Transformer モデルの推論をいろいろ挟んいるが、結構速い小型の日経xsmall モデルのおかげ 👉更なる高速化のチューニングも可能だが、そこの最適化は必要に応じて

Slide 47

Slide 47 text

まとめ

Slide 48

Slide 48 text

まとめ - 検索の流れ前処理: クエリ展開本質的な質問文の作成多角的な質問サブクエリ生成検索時の条件オプション抽出検索1st: ハイブリッド検索密ベクトル（文脈+ 汎化性能重視）: BAAI/bge-m3 疎ベクトル（キーワード+ 日経ドメイン重視）: 日経SPLADE 👉両方のモデルを組み合わせたハイブリット検索検索2nd: Judge モデルの適用日経Judge モデルで「LLM に有益な情報」で関連性スコアの付与 👉ソート & 関連性の低い結果をフィルタリング

Slide 49

Slide 49 text

まとめ - Ask! NIKKEI RAG 検索技術の深層 RAG で求められる情報検索システム 👉 検索結果を活用するのは LLM 通常の検索改善前処理ではLLM を用いたクエリ展開検索1st で、全体からある程度良い結果を取得 AI ・LLM からの利用に向けた改善検索2nd では LLM が検索結果を評価した結果を直接学習したモデルを適用 👉 更に LLM に役立つ結果を提供

Slide 50

Slide 50 text

これからの情報検索技術自然言語処理やマルチメディアデータを使うなら、LLM(VLM) の活用が欠かせない時代に今までは人が介入しないと得られない・作れないデータも、LLM の活用で作成可能工夫次第でさまざまな改善が可能ドメイン特化モデルの作成が簡単にデータを活かしたいサービスで必要になるのは、ドメイン特化性能なことも多いハズドメイン特化性能が出る" 小型な" モデルもサクッと作れる時代リアルタイムでレイテンシ( 速度) が必要な用途にも対応

Slide 51

Slide 51 text

とても情報検索面白い!!1 LLM と組み合わせることで、今まで難しかったこと( データセット作りなど) が可能に情報検索とLLM を活用したプロダクト作りも、新しいことだらけで楽しい日経さんはLLM を活用したプロダクト作りに興味がある、AI/UX エンジニア・データサイエンティスト・情報検索エンジニア等々を募集中みたいですよ…!? 活用できるデータも山ほどあって面白そうですね!? https://hack.nikkei.com/

Slide 52

Slide 52 text

ご清聴ありがとうございました今回の検索を活用している Ask! NIKKEI は現在ベータテスト中です提供まで、しばしお待ちください 🙏