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