【ITニュース解説】What a Small RAG Fine-Tuning Experiment Can Actually Prove

大規模言語モデル（LLM）は、人間のような自然な文章を生成できる強力なAIだが、時には事実に基づかない情報を生成してしまうことがある。この問題を解決し、より信頼性の高い回答を得るための技術の一つが、RAG（Retrieval Augmented Generation）システムである。RAGは、ユーザーからの質問に対し、あらかじめ用意された大量の資料（ドキュメントやデータベースなど）の中から関連情報を検索し、その情報を根拠としてLLMが回答を生成する仕組みだ。これにより、LLMが「知ったかぶり」をして誤った情報を生成するリスクを低減できる。

RAGシステムは主に三つの段階から構成される。第一段階は「検索（Retrieval）」で、ユーザーの質問に関連する可能性のある情報を、データソースからできるだけ多く集め出す。第二段階は「リランキング（Reranking）」で、検索で集められた多数の情報の中から、質問に対して最も適切で、回答生成に本当に役立つ情報を厳選し、その順序を並べ替える。そして第三段階は「生成（Generation）」で、リランキングで選ばれた最適な情報を用いて、LLMが最終的な回答を作り出す。

今回の記事で述べられているのは、このRAGシステムの第二段階である「リランカー」の性能向上を目指したファインチューニング（微調整）実験についてだ。ファインチューニングとは、すでに学習済みのAIモデルを、特定の目的やデータに合わせてさらに学習させ、性能を向上させる手法である。この実験の目的は、リランカーをファインチューニングすることで、システムがより適切な情報を上位に提示できるようになり、結果としてより高品質な回答を生成できるかを検証することにあった。

実験では、情報から数値的な表現（埋め込み）を作り出す「埋め込みモデル」としてintfloat/multilingual-e5-smallを、情報の順序を並べ替える「リランカー」としてcross-encoder/mmarco-mMiniLMv2-L12-H384-v1を、そして最終的な回答を生成する「回答生成器」としてQwen/Qwen3-1.7Bという具体的なAIモデルが使用された。これらのモデルは実際にローカル環境のCPUで動作させられたという。この実験の重要なポイントは、RAGシステム全体をファインチューニングしたのではなく、リランカーの「重み」（モデルが学習によって獲得した知識を表す数値）だけを調整したことだ。埋め込みモデルと回答生成器は固定されたままで、リランカーの変更がシステム全体にどのような影響を与えるかを独立して評価しようとしたのである。

実験の比較には、四つの異なる構成が用意された。 パターンAは、検索もリランキングも行わず、回答生成器のQwenのみで回答を作成する。 パターンBは、検索機能（BM25とE5という手法を組み合わせたもの）を追加するが、リランキングは行わない。 パターンCは、パターンBと同じ検索機能に加え、事前学習済みのリランカーを使用する。 そしてパターンDが今回の実験の核であり、パターンCと同じ検索機能と、今回ファインチューニングによって調整されたリランカーを使用する。 これらのパターンを比較することで、検索機能の有無（A対B）、事前学習済みリランカーの効果（B対C）、そしてファインチューニングしたリランカーがどれだけ効果的か（C対D）を段階的に検証できるように設計されている。特にDとCの比較が、リランカーのファインチューニングが実際に役立つのかを直接的に示す部分だ。

ファインチューニングのプロセスでは、単にトレーニングコマンドを実行するだけでなく、実際にモデルが学習したことを確認するための厳密な検証が行われた。これは、システム開発において「実はモデルの学習がうまく行われていなかった」「間違ったバージョンのモデルを保存したり読み込んだりしていた」といった実装上のミスを防ぐために非常に重要である。具体的には、リランカーの重みが実際に更新されたか、保存されたチェックポイント（学習途中のモデルの状態）が意図したものと一致しているか、そしてそのチェックポイントを読み込んだ時に期待通りの予測ができるか、という点が細かく確認された。

今回の実験で得られた最も注目すべき結果は、モデルの学習には使用せず、性能評価のために取っておいた合成データセットにおいて、ランキングゲイン（情報の順序付けの品質向上）がゼロだったことである。これは、ファインチューニングによってリランカーを調整しても、調整前のリランカーと比較して情報の順序付けの品質に改善が見られなかったことを意味する。評価に使用されたデータには、回答可能な質問が二つ、回答不能な質問が一つ含まれていた。特に、その二つの回答可能な質問に対しては、調整前のリランカーも調整後のリランカーも、nDCG@5（ランキングの品質を示す一般的な指標）で1.0という「完璧な」スコアを達成してしまった。

この「完璧なスコア」が出てしまったという事実が重要だ。これは、今回の小さな合成データセットにおいては、すでに事前学習済みのリランカーが、質問に対して最適な情報を完璧に並べ替える能力をすでに持っていたため、ファインチューニングによるさらなる改善の余地がなかったことを示している。つまり、このデータセットはファインチューニングが効果を発揮するほど難しい問題を含んでいなかった、ということになる。この結果は一見すると「ファインチューニングは失敗だった」と捉えられがちだが、記事の筆者はこの結果が「有用だった」と述べている。それは、今回のトレーニングと評価のパイプラインが正しく機能していること、そして安易に「改善した」と主張する理由がないことを明確に示せたからだ。

評価の厳密性を高めるため、結果の確認には三つの異なる側面が含まれていた。一つは「検索の関連性」で、システムが必要な情報をどれだけ適切に探し出して順序付けできたかを見る。二つ目は「引用の整合性」で、生成された回答が参照している情報源が実際に存在し、適切な文脈に属しているかを確認する。そして三つ目は、最も重要な「人間による事実確認と有用性のレビュー」で、回答が引用された情報によって本当に裏付けられているか、事実として正しいか、そしてユーザーにとって有用かを人間の目で評価する。今回の実験では、この人間によるレビューはまだ完了しておらず、今後の課題として残されている。現時点では、合成データ上でのランキング結果のみが検証されたに過ぎない。

実験の再現性と信頼性を確保するため、すべての設定は厳密に管理された。具体的には、使用するデータセット、システムの構成、モデルの種類、そしてモデルの重みのハッシュ値（ファイルの同一性を確認するための値）に至るまで、評価を行う前に「フリーズ」され、変更されないように固定された。これにより、意図しない設定の変更や、以前の結果の再利用による評価の歪みを防ぐ。また、ファインチューニング後の最適なモデルの選択は、ホールドアウトされたテストデータの結果を見てから行うのではなく、別の検証データの結果だけに基づいて決定する。これは、テストデータにモデルが過度に適合してしまい、一般的な性能を測れなくなることを避けるための工夫である。

今回の実験は合成データで行われたが、実際のデータ（リアルコーパス）を使った実験も並行して進められている。しかし、実際のデータでの実験には、さらなる複雑な課題がある。例えば、回答の根拠となる情報（ポジティブなパッセージ）や、そうではない情報（ネガティブなパッセージ）を正確にアノテーション（正解ラベルを付与する作業）すること、プライバシーに関するレビュー、そして重複する質問の扱いなど、様々な準備が必要となる。これらの準備が整わないうちにファインチューニングを進めても、意味のある結果は得られない。

筆者は、今後の評価で改善したい点もいくつか挙げている。例えば、より難しいシナリオ（似たような製品サイズ、矛盾する事実、曖昧な要求など）を評価データに含めること、失敗の原因を「検索漏れ」「誤ったランキング」「根拠のない主張」といった具体的なカテゴリで報告すること、そして人間による回答の品質評価を必ず行うことだ。また、モデルのロード時間や実際の推論時間といった運用上の側面も、測定して報告する必要があると考えている。

結論として、今回の小規模なRAGリランカーのファインチューニング実験は、選択されたモデルが制御されたローカルパイプラインで正しく動作し、事前学習済みのリランカーを調整、保存、ロード、そして比較できることを実証した。しかし、使用した合成ホールドアウトデータセットにおいては、ランキングゲインはゼロだった。この結果は、ファインチューニングが常に即座の性能向上をもたらすわけではないこと、そして特にデータセットが簡単すぎると改善の余地が見えないことを示している。次の重要なステップは、より困難で、独立したレビューを受けた実際のドメイン固有の事例を用いた評価と、人間の目による回答の品質評価にかかっていると言える。この実験は、RAGシステム開発における厳密な検証と評価の重要性を教えてくれる貴重な事例である。