生成AIを活用したRAG（検索拡張生成）システムの構築、進んでいますか？
「社内ドキュメントを読み込ませたはずなのに、的外れな回答が返ってくる」
「ドキュメントには書いてあるのに、『分かりません』と答えられる」
実務の現場では、こうした課題に直面するケースが少なくありません。多くのエンジニアやプロジェクトマネージャーが、プロンプトを少し書き換えては「良くなった気がする」「いや、別の質問では悪化したかも」と、感覚的な調整を繰り返しているのが実情です。
しかし、「感覚」に頼ったチューニングでRAGの実用化レベルに到達するのは非常に困難です。
RAGシステムは、複数の複雑な処理が噛み合って動作する仕組みです。どこがボトルネックになっているのかを客観的に特定するための「定規（評価指標）」を持たなければ、効率的な仮説検証と改善のサイクルは回りません。
そこで今回は、日本語のAIモデル評価において標準的となりつつあるベンチマーク群「JGLUE」の中から、特にRAGの性能向上に直結する2つの指標――JSTSとJSQuADについて解説します。
これらを単なる「学術的なデータセットの名前」として暗記する必要はありません。今回は、これらをRAGにおける「検索力」と「読解力」を測るための実践的なツールとして捉え直し、開発現場でどのように活かせるのか、その本質を分かりやすく紐解いていきましょう。
なぜRAGの精度改善は難しいのか？
RAGシステムを構築した直後、多くのチームが直面するのが「期待値と現実のギャップ」です。しかし、単に「精度が低い」と嘆くだけでは解決しません。まずは、その失敗がどのプロセスで起きているのかを論理的に分解する必要があります。
「検索（Retriever）」と「生成（Generator）」の壁
RAGは、大きく分けて2つの機能が協力して動く「二人三脚」のシステムです。
- 検索担当（Retriever）: ユーザーの質問に関連する情報を、膨大なデータベースから探し出してくる役割。
- 生成担当（Generator）: 検索担当が持ってきた情報を読み込み、ユーザーへの回答文章を作成する役割。
精度が出ない時、このどちらが原因となっているのでしょうか。
例えば、「2024年の就業規則の変更点は？」という質問に対し、AIが不適切な回答をしたと仮定します。
- ケースA（検索の失敗）: そもそも「2024年版の就業規則」のドキュメントを見つけられず、2020年の古い規則を拾ってきてしまった。
- ケースB（生成の失敗）: ドキュメントは正しく拾えていたのに、AIがその内容を正確に読み取れず、事実と異なる内容を生成（ハルシネーション）してしまった。
ケースAなら検索モデル（Embeddingモデルなど）を改善すべきですし、ケースBなら生成モデル（LLM）の読解力や指示に従う能力を改善すべきです。この切り分けができていないと、「検索が悪いのにプロンプトばかりいじる」といった非効率なアプローチに陥ってしまいます。
評価データセットがないと改善サイクルが回らない理由
ここで問題になるのが、「どうやって検索が成功したか、生成が成功したかを判定するか」です。
人間が手作業で数千件のログを目視確認して「これはOK、これはNG」と判定するのは、初期段階では有効ですが、開発が進むにつれて限界を迎えます。モデルを微調整するたびに全件チェックを行うのは現実的ではありません。
そこで必要になるのが、自動的にスコアを算出してくれる「評価データセット」です。
「この質問に対しては、このドキュメントが選ばれるべきである（正解データ）」
「この質問とドキュメントの組み合わせなら、こういう回答が生成されるべきである（正解回答）」
こうした正解があらかじめ用意されていれば、AIモデルを入れ替えた瞬間に「スコアが5ポイント上がった」と実証データに基づいて定量的に判断できます。この「客観的な数値」こそが、開発者を迷いから救い、確実な改善へと導く羅針盤となるのです。
【基礎用語】RAG性能評価の全体像
評価の重要性が理解できたところで、具体的にどのような指標を用いればよいのでしょうか。日本語の自然言語処理（NLP）分野において、モデルの基礎能力を測るための標準的なベンチマークとしてJGLUE（Japan General Language Understanding Evaluation）が広く活用されています。
ベンチマークスコアとは
PCやスマートフォンの性能を比較する際、「Geekbench」のようなベンチマークソフトのスコアを参考にすることがあるでしょう。これと同様に、AIモデルにも「言語理解能力」を客観的に測定するための統一テストが存在します。
英語圏では「GLUE」や「SuperGLUE」といったベンチマークが標準となっていますが、言語構造が大きく異なる日本語では、これらをそのまま適用することはできません。そこで、日本の研究チームが中心となり、日本語に特化した総合評価セットとして構築されたのがJGLUEです。
JGLUE（日本語言語理解ベンチマーク）の位置づけ
JGLUEは、AIモデルが日本語をどれだけ正確かつ深く理解しているかを測るための「総合体力測定」のような役割を果たします。最新のLLM（大規模言語モデル）は推論能力が飛躍的に向上していますが、その土台となる基礎的な言語処理能力を確認するための指標として、JGLUEは依然として重要な位置を占めています。
具体的には、以下の4つの主要タスクで構成されています。
- JSTS（文章類似度判定）: 2つの文の意味がどれくらい似ているかを数値化する能力を測ります。
- JSQuAD（質問応答）: 与えられた文章の中から、質問に対する答えを正確に抜き出せるかを測ります。
- JCommonsenseQA（常識推論）: 一般常識に基づいた推論が可能かを問う選択式問題です。
- JNLI（自然言語推論）: 文同士の論理的な関係（含意、矛盾、中立）を正しく分類できるかを評価します。
これらはすべてAIの基礎能力として重要ですが、RAG（検索拡張生成）システムの開発という文脈において、特に重要度が高いのがJSTSとJSQuADです。
なぜなら、RAGを構成する2つの核心プロセス――「検索（Retriever）」は類似度判定（JSTS）の精度に依存し、「生成（Generator）」による回答作成は質問応答能力（JSQuAD）に依存するからです。
企業内ドキュメントを扱うRAGにおいては、テキストの「検索力」と「読解力」が精度のボトルネックになりがちです。ここからは、この2つの指標についてさらに詳しく解説していきます。
【用語解説1】JSTS：AIの「検索力」を測る物差し
まず一つ目の定規、JSTS (Japanese Semantic Textual Similarity) です。これは、RAGにおける「検索担当（Retriever）」の実力を測るために不可欠な視点を提供してくれます。
Semantic Textual Similarity（文章類似度）とは
JSTSは、2つの日本語の文章が与えられたとき、その意味がどれくらい似ているかを0から5までの数値で判定するタスクです。
例えば、以下の2つの文を見てください。
- 文A：「猫が庭で遊んでいる」
- 文B：「庭で猫がじゃれている」
この2つは、使っている単語や語順は違いますが、意味している情景はほぼ同じです。人間なら「これらは同じ意味だ」と直感的に分かります。しかし、従来の単純なキーワードマッチング（単語が含まれているかどうかだけの判定）では、これらを「別物」と判断してしまうことがありました。
JSTSは、こうした「意味的な近さ」をAIが正しく理解できているかをテストします。
- スコア5: 全く同じ意味。
- スコア3: 一部の詳細が異なるが、主要な内容は同じ。
- スコア0: 全く関係ない。
このように、グラデーションで類似性を評価できるのが特徴です。
RAGにおける活用シーン：Retrieverの選定
では、これがRAG開発にどう関係するのでしょうか。
最近のRAGでは、ベクトル検索（Vector Search）という技術が主流です。これは、文章を「意味のベクトル（数値の羅列）」に変換し、ユーザーの質問ベクトルと近い場所にあるドキュメントベクトルを探し出す手法です。
この「文章をベクトルに変換するモデル（Embeddingモデル）」の性能が低いと、どうなるでしょうか。
ユーザーが「経費精算のやり方を知りたい」と質問したのに、AIは「経費」という単語だけに反応して「経費削減の目標数値」という全く関係ないドキュメントを持ってきてしまうかもしれません。
JSTSのスコアが高いモデルを使うということは、ユーザーの「質問の意図」と、ドキュメントの「意味」を正しくマッチングできる可能性が高いことを意味します。
つまり、RAGの検索精度を上げたければ、まずはJSTSのスコアが高いEmbeddingモデルを選定することが第一歩となります。具体的には、OpenAIの最新Embeddingモデルや、日本語処理に定評のあるE5シリーズの最新版などが候補に挙がります。
JSTSは、モデルが新しくなった際にも、その「検索力」が自社の要件を満たしているかを客観的に評価するための、変わらぬ基礎体力テストとして機能します。
【用語解説2】JSQuAD：AIの「読解力」を測る物差し
次に二つ目の定規、JSQuAD (Japanese Stanford Question Answering Dataset) です。こちらは、RAGにおける「生成担当（Generator）」、つまりLLM（大規模言語モデル）の性能を見極めるために重要です。
Question Answering（質問応答）とは
JSQuADは、もともとスタンフォード大学が作成した「SQuAD」という有名なデータセットの日本語版です。このタスクの形式は非常にシンプルで、RAGのプロセスそのものです。
AIには以下の2つが与えられます。
- 文脈（Context）: Wikipediaの記事などの短い文章。
- 質問（Question）: その文章の内容に関する質問。
AIのミッションは、「文脈の中から、質問の答えとなる部分を正確に抜き出すこと」です。
例えば：
- 文脈: 「徳川家康は、1603年に江戸幕府を開いた。」
- 質問: 「徳川家康が江戸幕府を開いたのはいつですか？」
- 正解: 「1603年」
一見簡単そうに見えますが、文章が長く複雑になったり、答えが直接的に書かれていなかったりする場合、AIの「読解力」が試されます。
RAGにおける活用シーン：Generatorの回答精度
RAGにおいて、検索担当（Retriever）が良いドキュメントを取ってきたとしても、生成担当（LLM）がそれを正しく読み取れなければ意味がありません。
よくある失敗例として、検索されたドキュメントには「Aプランの料金は月額980円」と書いてあるのに、LLMが事前学習知識（インターネット上の古い情報など）に引きずられて「Aプランは無料です」と答えてしまうケースがあります。これはLLMが「与えられた文脈（ドキュメント）を最優先して答えを探す」という能力、つまりJSQuADで測られる能力が不足している場合に起こりやすい現象です。
JSQuADのスコアが高いモデルは、「与えられた参考資料に忠実に答える」という、RAGのGeneratorに最も求められる資質を持っています。
もし構築中のRAGが、ドキュメントの内容を無視して事実と異なる回答をする傾向があるなら、それはGeneratorとして採用しているLLMのJSQuAD的な能力、すなわち「読解力」と「抽出能力」に課題があると考えられます。
JSTSとJSQuADの併用がもたらす最適化サイクル
ここまで見てきたように、JSTSは「検索」、JSQuADは「生成」に対応しています。重要なのは、これら片方だけでなく、両方の指標をセットで意識し、仮説検証を行うことです。
ボトルネックの特定：検索が悪いのか、生成が悪いのか
RAGの精度向上プロジェクトでは、以下のようなサイクルを回すことが効率的です。
- 現状分析: ユーザーからの質問と回答のログを集める。
- 検索評価 (JSTS的視点): ログを確認し、「そもそも正解が書かれたドキュメントが検索結果の上位（Top-K）に含まれているか？」をチェックする。
- 含まれていない場合 → 検索モデル（Retriever）の課題。Embeddingモデルの変更や、チャンク分割（文章の区切り方）の見直しが必要です。
- 生成評価 (JSQuAD的視点): 正解ドキュメントは取得できているのに、回答が間違っているかをチェックする。
- 間違っている場合 → 生成モデル（Generator）の課題。プロンプトエンジニアリングで「文脈のみに基づいて回答せよ」と指示を明確にするか、より読解力の高いLLMへの変更、あるいはファインチューニングを検討します。
ファインチューニングへの応用
さらに高度な対策として、独自のデータを用いてモデル自体を再学習（ファインチューニング）させる場合も、この2つの視点が役立ちます。
- 検索精度を上げたい場合: 組織内の専門用語や特有の言い回しを学習させるために、JSTSのような「類似文章ペア」のデータセットを作成して学習させます。「『サビ残』と『サービス残業』は同じ意味」といった知識をモデルに教え込むアプローチです。
- 回答精度を上げたい場合: 業務マニュアルなどを元に、JSQuADのような「質問・回答・根拠箇所」のセットを作成して学習させます。「このマニュアルの記述に対しては、こう答えるのが正解」というパターンを学習させるのです。
このように、JSTSとJSQuADの構造を理解していれば、専用の学習データを作成する際の「型」としても有効に活用できます。
まとめ：正しい「定規」を持って開発に挑もう
RAGシステムの精度向上は、継続的な改善が求められるプロセスです。しかし、客観的な指標を持たずに試行錯誤を繰り返すのと、正確な評価基準を持って論理的に進めるのとでは、到達できる精度も開発スピードも全く異なります。
今回解説した2つの指標を、システム最適化のためのツールとしてぜひ活用してください。
- JSTS: AIの「検索力」を測る定規。ユーザーの意図とドキュメントの意味をつなぐ精度の高さを測ります。
- JSQuAD: AIの「読解力」を測る定規。見つけ出した情報から正確に答えを導き出す能力を測ります。
まずは、現在使用しているモデルがJGLUEベンチマークでどの程度のスコアを出しているかを確認することから始めてみましょう。そして次のステップでは、これらのデータセットの形式を参考に、「独自データ版JSTS」「独自データ版JSQuAD」といった評価セットの作成に挑戦してみてください。実証データに基づいた評価サイクルを確立することで、RAG開発は「感覚的な調整」から「論理的なエンジニアリング」へと進化するはずです。
コメント