RAFTデータセット構築（ラフトデータセットコウチク）
RAFTのデータセット構築は、ドメイン固有のコーパスから質問-回答ペアを生成し、各質問に対してoracle文書（正解を含む文書）とdistractor文書（無関係な文書）を割り当てるプロセスである。Chain-of-Thought形式の教師回答の生成と品質管理が構築の鍵となる。
データセット構築の概要
RAFTデータセット構築は、RAFTファインチューニングの成否を決定する最も重要な工程である。高品質な訓練データがなければ、どれだけ訓練パラメータを最適化しても十分な性能は得られない。構築プロセスは大きく4つのフェーズに分かれる。
| フェーズ | 内容 | 出力 |
|---|---|---|
| 1. コーパス準備 | ドメイン文書の収集・前処理 | クリーンな文書セット |
| 2. 質問生成 | 文書から質問を自動/手動生成 | 質問リスト |
| 3. 文書割り当て | oracle/distractor文書の選定 | 質問-文書マッピング |
| 4. 回答生成 | CoT形式の教師回答を生成 | 完成データセット |
データセットの規模は、ドメインの複雑さと要求精度に応じて数千〜数万サンプルが必要である。論文の実験では、PubMedQA（医療）やHotpotQA（一般知識）などの既存ベンチマークを使用した評価が行われているが、実務ではドメイン固有のデータセットをゼロから構築する必要がある。
コーパス準備と前処理
ドメイン固有コーパスの準備は、RAFTデータセット構築の出発点である。
文書収集の指針
| ソース | 例 | 注意点 |
|---|---|---|
| 社内文書 | マニュアル、FAQ、議事録 | 機密情報の取り扱い |
| 公開文書 | 技術仕様書、論文、規格 | ライセンス確認 |
| 構造化データ | DB記録、ログ、CSV | テキスト化が必要 |
| Web情報 | ブログ、フォーラム、Q&A | 品質のばらつきが大きい |
前処理パイプライン
- テキスト抽出：PDF、Word、HTMLなどからプレーンテキストを抽出。レイアウト情報はできる限り保持する（表、リスト構造など）
- チャンキング：文書を適切なサイズのチャンクに分割。典型的には300〜1000トークンが1チャンク。文書の意味的まとまりを保持するよう分割点を選択する
- メタデータ付与：各チャンクにソース文書ID、セクション情報、作成日時などのメタデータを付与
- 重複排除：類似度の高いチャンクを検出・統合し、訓練データの偏りを防止
- 品質フィルタリング：短すぎるチャンク、情報量の少ないチャンク（目次、ヘッダーのみ等）を除外
チャンキングの粒度はRAFT訓練の品質に直結する。チャンクが大きすぎるとdistractor文書との区別が容易になりすぎ（情報量の差が明確になるため）、チャンクが小さすぎるとoracle文書に十分な情報が含まれなくなる。
質問生成手法
質問生成はRAFTデータセットの中核工程であり、以下の手法が利用される。
LLMベース自動生成
最も効率的な手法は、GPT-4やClaude等の高性能LLMを使用した自動質問生成である。各文書チャンクを入力として、そのチャンクの内容に基づいた質問を生成させる。
プロンプト設計のポイント：
- 事実確認型（「〜とは何か」「〜の値はいくつか」）と推論型（「なぜ〜か」「〜の場合どうなるか」）をバランスよく生成
- 単一チャンクで回答可能な質問と、複数チャンクの統合が必要な質問を混在
- ドメイン固有の専門用語を含む質問と一般的な表現の質問を混在
- 質問の難易度を制御（初級・中級・上級）
既存QAデータの活用
ドメインに既存のFAQやQ&Aデータベースがある場合、それを出発点とする方法も有効である。既存のQAペアに対して文書チャンクを割り当て（oracle/distractor）、CoT形式の回答を新たに生成する。
質問の多様性確保
| 質問タイプ | 割合（目安） | 例 |
|---|---|---|
| 事実確認 | 30〜40% | 「RAFTのP比率の推奨範囲は？」 |
| 概念説明 | 20〜30% | 「distractor文書の役割を説明せよ」 |
| 比較分析 | 15〜20% | 「RAFTとDSFTの違いは？」 |
| 手順説明 | 10〜15% | 「RAFT訓練の実装手順は？」 |
| 推論・応用 | 10〜15% | 「retriever精度が低い場合のP比率は？」 |
Oracle文書とDistractor文書の選定
各質問に対するoracle文書とdistractor文書の選定は、データセットの品質を決定する重要な工程である。
Oracle文書の選定
Oracle文書は、質問の回答に必要かつ十分な情報を含む文書チャンクである。選定基準は以下の通り：
- 回答の根拠を含む：質問の回答を導出するために必要な情報が明示的に記載されている
- 自己完結性：oracle文書単独で（他の文書がなくても）回答を生成するのに十分な情報を含む
- 適切な粒度：回答に直接関連する情報が文書の主要部分を占め、無関係な情報が過度に含まれていない
Distractor文書の選定戦略
Distractor文書の選定戦略はRAFTの訓練効果に大きく影響する。以下の3つの戦略がある：
| 戦略 | 説明 | 難易度 | 効果 |
|---|---|---|---|
| ランダム選択 | コーパスからランダムにチャンクを選択 | 低 | 基本的なノイズ耐性 |
| トピック類似選択 | 同トピックだが回答と無関係なチャンクを選択 | 中 | 意味的識別能力の向上 |
| 高類似度選択 | Embeddingの類似度が高いが回答を含まないチャンクを選択 | 高 | 最高レベルのノイズ耐性 |
実践的には、3つの戦略を混合して使用するのが最も効果的である。たとえば、distractor5つのうち2つをランダム、2つをトピック類似、1つを高類似度から選択する構成が推奨される。
品質管理と検証
データセット構築後の品質管理は不可欠である。以下のチェックポイントを確認する。
自動チェック
- oracle文書と質問の意味的類似度が閾値以上であること
- CoT回答に引用が含まれていること
- 回答がoracle文書の内容と矛盾していないこと
- 質問の重複がないこと
- 各カテゴリの質問バランスが適切であること
人手チェック（サンプリング）
- ランダムサンプル（全体の5〜10%）を人手で検証
- oracle文書が実際に回答に十分な情報を含んでいるか
- distractor文書が本当に回答と無関係であるか
- CoT回答の推論が論理的であるか
- 引用箇所が正確であるか
| 品質指標 | 目標値 | 測定方法 |
|---|---|---|
| Oracle適切率 | >95% | 人手検証 |
| Distractor無関連率 | >90% | 自動+人手 |
| CoT引用正確率 | >90% | 自動チェック |
| 質問多様性スコア | >0.7 | Embedding分散 |
| 回答一貫性スコア | >0.85 | 自動検証 |
よくある質問
Q: データセット構築にかかるコストと時間はどの程度ですか？
コストはドメインの規模と要求品質に大きく依存する。1万サンプルのデータセットを構築する場合の目安として、（1）コーパス準備：1〜3日（既存文書がある場合）、（2）質問生成（LLM自動生成）：GPT-4使用で$200〜500程度のAPI費用と1〜2日、（3）文書割り当て：Embedding計算を含め半日〜1日、（4）CoT回答生成：GPT-4使用で$300〜800程度のAPI費用と1〜2日、（5）品質検証：2〜5日（人手チェック含む）。合計で1〜2週間、API費用$500〜1,300程度が目安である。
Q: 小規模なコーパス（数百文書程度）でもRAFTは有効ですか？
小規模コーパスでもRAFTは有効だが、いくつかの工夫が必要である。第一に、質問生成の段階で各文書から複数の質問を生成し、データ量を確保する。第二に、distractor文書の選択肢が限られるため、データ拡張（文書の一部を入れ替える、言い換えるなど）を積極的に活用する。第三に、過学習を防ぐため、LoRAのランクを小さく（8〜16）設定し、エポック数を抑える。数百文書から1,000〜3,000の質問-回答ペアを生成できれば、実用的な性能向上が見込める。
Q: distractor文書の数はいくつが最適ですか？
論文の実験では4〜5つのdistractor文書が標準的に使用されている。distractor数を増やすとノイズ耐性は向上するが、入力系列長が長くなり計算コストが増大する。また、distractor数が多すぎるとモデルがコンテキストを完全に無視してパラメトリック知識のみに頼る傾向が生じる場合がある。実践的には、実際のRAGパイプラインでretrieverが返す文書数に合わせるのが合理的である。retrieverがtop-5を返すなら、oracle1つ+distractor4つの構成が自然である。
Q: 既存のRAGベンチマークデータセットをRAFT訓練に転用できますか？
部分的に可能である。HotpotQA、Natural Questions、TriviaQAなどの既存ベンチマークには質問と正解文書（oracle）のペアが含まれているため、これにdistractor文書を追加し、CoT形式の回答を再生成することでRAFT訓練データに変換できる。ただし、ドメイン固有のRAFT訓練を目的とする場合、汎用ベンチマークのデータは補助的な役割にとどまり、主要なデータセットはドメイン固有コーパスから構築する必要がある。