Ask! NIKKEI RAG検索技術の深層

Ask! NIKKEI RAG検索技術の深層という内容で、#nikkei_tech_talk で発表した資料です。
検索システムでは、前処理でのクエリ展開・1stフェイズのハイブリット検索(マルチリンガルモデル + 日経用SPLADEモデル)、2ndフェイズの日経Judgeモデル(LLMの評価スコアをモデルに学習)という3段構え構成で構築しています。
また現実的な検索システム実現のため、小型なエンコーダモデルを使うことで、推論を高速化していることも、特徴の一つです。

https://nikkei.connpass.com/event/342099/

Transcript

1. Ask! NIKKEI RAG 検索技術の深層 舘野祐一 / @hotchpotch / id:secondlife 2025 年02 月06 日 - 日経電子版開発と記事検索の最前線
2. ※ 資料中のリンクは、PDF をダウンロードするとクリック出来ます
3. 自己紹介 舘野祐一, セコン, @hotchpotch https://secon.dev/ ソフトウェアエンジニア 一人法人の代表 Ask! NIKKEI プロダクトマネージャ 情報検索エンジニア 情報検索関連のオープンな活動 JQaRA: 検索拡張(RAG) 評価のための日本語 Q&A データセット JaCWIR: 日本語情報検索評価のための小規模で カジュアルなWeb タイトルと概要のデータセッ ト 日本語最高性能のReranker をリリース / そもそ も Reranker とは? 情報検索モデルで最高性能(512 トークン以下) ・ 日本語版SPLADE v2 をリリース 100 倍速で実用的な文章ベクトルを作れる、日 本語 StaticEmbedding モデルを公開
4. Ask! NIKKEI とは? 「広く知る。深く知る。 」新しいニ ュース体験 Ask! NIKKEI は、記事を読んでいて疑問が生じた 瞬間に、日経電子版の記事からAI がわかりやす く回答するサービスです。 キーワードや背景知識の補足から専門的な深堀 りまで、 「読む・疑問・解決」をその場で実現 し、読者に「広く知る」 「深く知る」新しいニュ ース体験を提供します。 ( 現在・一部ユーザを対象にベータ公開中)
5. RAG （Retrieval Augmented Generation ）とは RAG （Retrieval Augmented Generation ）とは、LLM （大規模言語モデル）などの生成系AI に外部データベース を組み合わせ、より正確かつ豊富な回答を導く仕組み。 「Retrieval （検索） 」と「Generation （生成） 」の組み合わせ 必要情報を検索し、その情報をもとに回答を生成する二段構えで、最新情報や専門性を補強。 誤情報リスクの軽減と透明性 信頼性の高い情報ソースに限定して検索し、参照元を提示できるため、回答の正確性と信頼度を高められ る。 つまり… 👉日経電子版とは相性が良いですね！
6. RAG で求められる情報検索システム 検索結果を活用するのは LLM クエリーに対して「LLM の生成結果が」有益になる記事を返す 人間よりも、AI に最適な結果 速度も、ある程度速い方が良い AI Agent などは、何度も検索をして熟考する 人間ならたくさん検索は億劫( ≒高コスト) だが、AI なら低コスト
7. 今回作った情報検索システムの流れ
8. 今回作った情報検索システムの流れ 検索前処理 検索する前(pre) の処理 クエリー展開 検索1st: 記事全てを対象に、関連のある記事を取得 検索2nd: 1st で絞り込んだ記事から、さらにフィルタリング・並べ替え
9. 検索前処理
10. クエリー展開 入力文を、検索に適したものに展開 クエリ例: 🗣" 直近一年間の内容で、Android とiOS の良いこと悪いところを比較してまとめ て。出力には比較の表を入れること。"
11. クエリ展開・検索時のオプションを抽出 🗣" 直近一年間の内容で、Android とiOS の良いこと悪いところを比較してまとめ て。出力には比較の表を入れること。" " 直近一年間の内容で" これはクエリの中での条件文 条件文から検索時に必要なオプションを抽出 検索オプションの抽出 現在が2025 年2 月6 日なら: 👉 start_date: 2024年2月6日
12. クエリ展開・本質的な質問文を作成 🗣" 直近一年間の内容で、Android とiOS の良いこと悪いところを比較してまとめ て。出力には比較の表を入れること。" 「比較してまとめて」 「出力には比較の表を入れること」などは、LLM がまとめる際に期待する指示 これらを取り除いたり要約して、ユーザが望む本質的な質問文を作成 本質的な質問 👉 AndroidとiOSの良いところ悪いところを知りたい
13. クエリ展開・クエリを複数に分ける 👉 AndroidとiOSの良いところ悪いところを知りたい 本質的な質問では引っかかりにくいものを、複数( サブクエリ) に分ける 本質的な質問を分解することで、多様なドキュメントを取得可能に サブクエリ展開例 Androidの良いところは？ iOSの良いところは？ Android の悪いところは？ iOSの悪いところは？
14. クエリ展開まとめ 検索条件抽出: 検索時のオプション( 時刻指定など) の抽出 本質的な質問文を作成: 入力から、本当に質問したいことは何か、を作成 サブクエリ展開: 本質的な質問を分解することで、多様なドキュメントを取得 実現方法 今はルールベース+LLM でクエリ展開 クエリ展開は、アプリケーションor 検索システム側、どちら側がやっても良い 今はオプションでオンor オフが可能に アプリケーション側なら、さらにUX を加味したクエリ展開が可能 直前に読んだ記事は何か、ユーザの興味関心は、等々の考慮
15. 検索1st, 2nd の前に…
16. 日経小型エンコーダモデルの作成 👉 このモデルを使った下流タスクが各々で登場 👉 基盤となるモデルを作ることで、他のタスクに応用
17. 日経小型エンコーダモデルの作成 日経電子版記事で学習した小型のエンコーダモデルを作成 エンコーダ BERT など LLM に比べると、パラメータが小さい 文章全体の特徴理解に強い デコーダ LLM など パラメータが基本大きい 次の1 文字を予想・文章生成に強い
18. 「小型」モデル？ Transformer 層のレイヤーパラメータ bert-base のレイヤーパラメータは 86M LLM はとても小さくても、500M 弱( 例:qwen2.5-0.5B) 今回作成したモデル 👉 わずか11M 小さいメリット 学習が速い 低GPU リソースで学習可能 / トライ& エラーがしやすく、試行回数を増やせる 推論が速い 11M ならbert-base の約8 倍速で推論可能 / リアルタイム環境で高速に実行可能 👉レイテンシが重要な検索では価値が高い
19. 日経トークナイザーの作成 モデル作成の前準備 日経の記事を中心に sentencepiece + unigram で学習したトークナイザー 例: " インバウンドの成功事例は?" 日本語BERT: イン , バウ , #ンド , の , 成功 , 事例 , は , ? 日経トークナイザー: インバウンド , の , 成功 , 事例 , は , ? 日経電子版の頻出語彙は1 トークンに
20. 日経小型エンコーダモデル - " 日経xsmall" の作成(1) Microsoft の mMiniLM-v2-L6-H384 をベースにファインチューン mMiniLM-v2-L6-H384: 👉マルチリンガル小型蒸留モデル 大元は meta の xlm-roberta-large 日経トークナイザに差し替えて、単語 embeddings をマージ ロンドン: mMiniLM では" ロ", " ン", " ド", " ン" にトークナイズされる 日経トークナイザでは「ロンドン」なので、単純に" ロ", " ン", " ド", " ン" の embeddings の平均で " ロンドン" にマージ 具体的なやり方 XLMRobertaTokenizer を日本語で学習させて動かす - 既存の学習済みマルチリンガルモデルの tokenizer を、日本語のものへ差し替えたい
21. 日経小型エンコーダモデル - " 日経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 日かからなかった( ハズ)
22. 検索1st: 記事全体から、関連のある記事を取得
23. 検索1st: 記事全体から、関連のある記事を取得 記事データから、質問に関連する記事を取得 大量の記事から、関連する top-N 個をハイブリット検索で取得 ハイブリット検索: 👉 異なる検索結果をまとめ合わせる手法 よくあるハイブリット検索例: 1. transformer 検索用モデルを使った、文章全体の文脈を考慮した密ベクトル検索 👉 文脈に強い 2. BM25 を使った、単語の出現頻度ベースの疎ベクトル検索 👉 単語( キーワード) に強い 1. 2. では検索結果に方向性の違いが出るため、両方をマージした検索結果を使うことで、より良質な 結果に
24. Ask! NIKKEI でのハイブリット検索 👉以下の組み合わせ結果を利用 文脈を重視した密ベクトル検索 汎化性能が高い高性能モデルを選択 今は BAAI/bge-m3 の密ベクトルを利用 キーワードを重視した疎ベクトル検索 日経電子版ドメインに特化した検索モデルを独自に作成 後ほど出てくる👉日経SPLADE モデル
25. 記事検索用データセットの作成 🤔 なぜデータセットを作るの? 👉 検索評価や検索モデル作成には、データセットが必要 記事を文脈と文章長で分割し、1~10 前後のチャンク( 部分テキスト) に 今回は約100 万件のチャンクを作成 それに紐づく、クエリ（質問文）を合成データセットとして作成 学習・検索評価用にハードネガティブサンプリングも ハードネガティブ≒正解のチャンクに似ているが正解ではないデータ このデータを学習することで「似ているけど違う」判定力が身に付く
26. 合成データセットとは? 検索の学習・評価には、クエリ( 質問文) と正解文( チャンク) 、二つのペアが最低必要 チャンクはあるので、質問をLLM に作らせる 👉合成データセット 同一記事では別チャンクだったとしても、同じ質問文をLLM が作りがち 複数チャンクから一括してクエリを作ることで、被りを抑える
27. 日経SPLADE モデルの作成 SPLADE は、キーワード( 単語トークン) 特徴に強い、ニューラルネットワークの情報検索モデル 情報検索モデルで最高性能(512 トークン以下) ・日本語版SPLADE v2 をリリース BM25 は基本完全一致 例: 「訪日外国人が好みな料理」を検索 SPLADE なら「インバウンドで人気の食べ物」と書いてある記事もヒット( しやすい) BM25 はヒットしない 密ベクトルモデルでもヒットするが、SPLADE は よりキーワードに強い 日経xsmall と記事検索用データセット + オープンな公開データセットを元にモデル学習 日経トークナイザは、日経の頻出単語で分割＝SPLADE と相性が良い イン , バウ , #ンド ではなく インバウンド 👉日経SPLADE の完成 ( 学習時間は約24 時間)
28. 日経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 層のレイヤパラメー タサイズを記載
29. 日経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
30. ハイブリット検索時の性能 実際の検索クエリのスコアで評価 Top-10 の関連性スコアの平均で算出 関連性スコア＝これから出てくる2nd フェイズ適用後の評価 ハイブリッド検索 >> bge-m3 単体検索 ≒ 日経SPLADE 単体検索 ハイブリットが一番良質なスコアに ( 全体的なロジックを日々変えているので、ざっくりとした評価)
31. 検索1st: Ask! NIKKEI でのハイブリット検索まとめ 文脈を重視した密ベクトル検索 汎化性能が高い高性能マルチリンガルモデルを利用 今は BAAI/bge-m3 の密ベクトルを利用 キーワードを重視した疎ベクトル検索 日経電子版ドメインに特化した検索モデルを作成 作成した、小型の日経SPLADE モデルを活用 👉二つの組み合わせ結果を利用することで、より良い結果スコアに
32. 検索2nd: さらに並べ替え・フィルタリング
33. 検索2nd: さらに並べ替え・フィルタリング 1st ( ハイブリッド検索) で記事全体から、ある程度絞り込み 2nd では、さらに並び替えとフィルタリング 0.0~1.0 の関連性スコアを付与 並び替え: 関連性順にソート フィルタリング: 関連性がないデータを削除
34. 検索2nd: 日経Judge モデルの作成 最適な検索結果は「LLM の視点から有益だ」と判定される文章 検索を利用するのはLLM LLM as a Judge LLM が検索結果を評価する この結果を直接学習させたもの 👉 日経Judge モデル
35. Reranker モデルの作成・学習 Judge モデルの学習前に… 日経 xsmall モデルをファインチューン 検索1st で作った記事検索学習用データセット100 万件や、公開データセットをもとに、Reranker を学習 👉 日経 Reranker の完成 ( 学習は約12 時間) Reranker って？ 質問文とドキュメントを1 つのコンテキストで評価 毎度計算が必要でコストが高いが、その分より良い検索結果を判定可能 日本語最高性能のReranker をリリース / そもそも Reranker とは?
36. Reranker って？
37. 日経 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
38. Judge 用データセットの作成 欲しい結果は「LLM の視点から有益だ」と判定される文章 検索を利用するのはLLM 1st の記事検索+ 日経Reranker でrerank( ソート) した結果Top-10 を元にLLM でスコア付 2: 質問の回答にズバリ役立つ文章 1: 質問の回答の補助に参考になる文章 0: 全く不要な文章 様々な傾向の16 万件の質問と、 1st検索 + rerank top-10 の160 万件のスコアで学習
39. Judge スコアのイメージ LLM が、回答生成時に有益そうかの指示プロンプトでスコア付 1st 検索 + 日経Reranker で上位でも、LLM でスコア付すると低い場合も ※なお上記はイメージで、実際の結果ではありません
40. Judge モデルの学習 日経Reranker モデルを、Judge データセットを元に、さらにファインチューン 0.0~1.0 へとスコアを変換 スコア2: 有益 → スコア 1.0 スコア1 : 間接的に有益 → スコア 0.8 スコア0 : 有益でない → スコア 0.0 有益or 有益でない、を強く分けたいため、スコア1( 間接的に有益) は0.8 にマッピング Reranker とほぼ同じように学習 👉日経Judge モデルの完成 ( 学習は約2 時間) 関連性スコアとして利用
41. 👉 Judge モデルとは、LLM の有益性判定スコアを学 習したモデル ☑️ Reranker は、従来のクエリと文章の関連度を学習 ☑️ Judge は"LLM にとって有益な結果" を学習・0.0~1.0 でスコアリング ☑️ 有益でない結果は、フィルタで除外可能
42. フィルタリングでの活用 1st stage の検索結果では、スコアによるフィルタリングが難しい コサイン類似度が0.5 は関連性が高いの？低いの？🤔 →場合による。関連性がかなり高いこともあれば、かなり低いこともある 閾値でのフィルタが難しい Judge モデルの場合 1.0 はLLM によって有益、0.0 は有益でないように学習されている スコアに一貫性があるので、スコアブーストをかけれる 例えば、時刻が過去の記事ほどスコアを下げる、などを行なっている 検索結果のスコア分布から、ざっくりフィルターの閾値が設定可能 👉ほぼ関係ない記事データをフィルタリングできる LLM でのハルシネーションの低下・入力トークンの削減に
43. Reranker, Judge の分布 Reranker は 1 or 0 で学習しているのでパキッと Judge は 0, 0.8, 1 で学習している・データセットのスコア分布も異なるので滑らか フィルタの閾値は、F2 スコアを中心に値を決める F2 スコアを使ったのは、関連情報の見逃しを最小限にしつつ、不要な情報を排除するため F2 はRecall( 関連情報をいかに漏らさず取得できるか) を優先しつつ、Precision( 取得した情報がいかに関連 性が高いか) も考慮できるため、最適なバランスを検討できる
44. フィルタリング活用例 「舘野重化学工業の今期の業績は？」 そもそも、そんな会社がない・検索対象データベースには無い 検索1st では「どこかの重化学工業会社の今期業績」の結果を取ってくる Judge スコアを使ってフィルターすると、関連性がないのでフィルターされ、ほぼヒットしない LLM が検索結果を元に生成せずとも「有益な検索結果がなかった」ことで処理分けが可能 LLM を使わずに「有益な情報がなかった」と即表示したり 例えば、有益な結果がなければ、クエリを変えて再検索なども可能 AI エージェントで、AI 自身が様々な処理を再起的に行う時に「そもそもデータがない」を理解でき るので役立つ " 舘野重化学工業の今期の業績は？" LLM が処理する前に、結果がなかったことが表示される（はず）
45. Reranker / Judge の速度と、小さなモデルの重要性 Reranker やJudge は、実は GPU をかなり使う処理 検索結果200 件を処理するなら、ざっくり 200 * 400 トークン ≒ 80,000 トークンの処理が毎回必要 この処理が小さな "11M" のモデルなら、100ms 以下で処理可能(GPU NVIDIA L4 の場合) " 小さな" ことで、そもそもの推論が速い 推論サーバに rust で書かれ FlashAttention が使える text-embeddings-inference を利用 Python で処理するより、二倍以上速い (FA 速い!) 👉 リアルタイム検索システムに組み込んでも、現実的な時間で処理が可能に
46. 検索速度は結構重要 AI や Agent と検索の相性の良さ 多様な視点でたくさん調べるコストが低い しかし「検索時間」が長ければ、応答性はどんどん悪くなる できる限り最良の結果を、できる限り短い時間で提供する 今回の検索システムでは、クエリ展開無しなら400ms, クエリ展開ありなら2000ms 弱で(LLM の処理が 1500ms…) の処理速度 Transformer モデルの推論をいろいろ挟んいるが、結構速い 小型の日経xsmall モデルのおかげ 👉更なる高速化のチューニングも可能だが、そこの最適化は必要に応じて
47. まとめ
48. まとめ - 検索の流れ 前処理: クエリ展開 本質的な質問文の作成 多角的な質問サブクエリ生成 検索時の条件オプション抽出 検索1st: ハイブリッド検索 密ベクトル（文脈+ 汎化性能重視）: BAAI/bge-m3 疎ベクトル（キーワード+ 日経ドメイン重視）: 日経SPLADE 👉両方のモデルを組み合わせたハイブリット検索 検索2nd: Judge モデルの適用 日経Judge モデルで「LLM に有益な情報」で関連性スコアの付与 👉ソート & 関連性の低い結果をフィルタリング
49. まとめ - Ask! NIKKEI RAG 検索技術の深層 RAG で求められる情報検索システム 👉 検索結果を活用するのは LLM 通常の検索改善 前処理ではLLM を用いたクエリ展開 検索1st で、全体からある程度良い結果を取得 AI ・LLM からの利用に向けた改善 検索2nd では LLM が検索結果を評価した結果を直接学習したモデルを適用 👉 更に LLM に役立つ結果を提供
50. これからの情報検索技術 自然言語処理やマルチメディアデータを使うなら、LLM(VLM) の活用が欠かせない時代に 今までは人が介入しないと得られない・作れないデータも、LLM の活用で作成可能 工夫次第でさまざまな改善が可能 ドメイン特化モデルの作成が簡単に データを活かしたいサービスで必要になるのは、ドメイン特化性能なことも多いハズ ドメイン特化性能が出る" 小型な" モデルもサクッと作れる時代 リアルタイムでレイテンシ( 速度) が必要な用途にも対応
51. とても情報検索面白い!!1 LLM と組み合わせることで、今まで難しかったこと( データセット作りなど) が可能に 情報検索とLLM を活用したプロダクト作りも、新しいことだらけで楽しい 日経さんはLLM を活用したプロダクト作りに興味がある、AI/UX エンジニア・データサイエンティスト・情 報検索エンジニア等々を募集中みたいですよ…!? 活用できるデータも山ほどあって面白そうですね!? https://hack.nikkei.com/
52. ご清聴ありがとうございました 今回の検索を活用している Ask! NIKKEI は現在ベータテスト中です 提供まで、しばしお待ちください 🙏