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 | 品質のばらつきが大きい |
前処理パイプライン
チャンキングの粒度はRAFT訓練の品質に直結する。チャンクが大きすぎるとdistractor文書との区別が容易になりすぎ（情報量の差が明確になるため）、チャンクが小さすぎるとoracle文書に十分な情報が含まれなくなる。
質問生成はRAFTデータセットの中核工程であり、以下の手法が利用される。
最も効率的な手法は、GPT-4やClaude等の高性能LLMを使用した自動質問生成である。各文書チャンクを入力として、そのチャンクの内容に基づいた質問を生成させる。
プロンプト設計のポイント：
ドメインに既存の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文書の選定戦略はRAFTの訓練効果に大きく影響する。以下の3つの戦略がある：
| 戦略 | 説明 | 難易度 | 効果 |
|---|---|---|---|
| ランダム選択 | コーパスからランダムにチャンクを選択 | 低 | 基本的なノイズ耐性 |
| トピック類似選択 | 同トピックだが回答と無関係なチャンクを選択 | 中 | 意味的識別能力の向上 |
| 高類似度選択 | Embeddingの類似度が高いが回答を含まないチャンクを選択 | 高 | 最高レベルのノイズ耐性 |
実践的には、3つの戦略を混合して使用するのが最も効果的である。たとえば、distractor5つのうち2つをランダム、2つをトピック類似、1つを高類似度から選択する構成が推奨される。
データセット構築後の品質管理は不可欠である。以下のチェックポイントを確認する。
自動チェック
人手チェック（サンプリング）
| 品質指標 | 目標値 | 測定方法 |
|---|---|---|
| Oracle適切率 | >95% | 人手検証 |
| Distractor無関連率 | >90% | 自動+人手 |
| CoT引用正確率 | >90% | 自動チェック |
| 質問多様性スコア | >0.7 | Embedding分散 |
| 回答一貫性スコア | >0.85 | 自動検証 |
コストはドメインの規模と要求品質に大きく依存する。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程度が目安である。
小規模コーパスでもRAFTは有効だが、いくつかの工夫が必要である。第一に、質問生成の段階で各文書から複数の質問を生成し、データ量を確保する。第二に、distractor文書の選択肢が限られるため、データ拡張（文書の一部を入れ替える、言い換えるなど）を積極的に活用する。第三に、過学習を防ぐため、LoRAのランクを小さく（8〜16）設定し、エポック数を抑える。数百文書から1,000〜3,000の質問-回答ペアを生成できれば、実用的な性能向上が見込める。
論文の実験では4〜5つのdistractor文書が標準的に使用されている。distractor数を増やすとノイズ耐性は向上するが、入力系列長が長くなり計算コストが増大する。また、distractor数が多すぎるとモデルがコンテキストを完全に無視してパラメトリック知識のみに頼る傾向が生じる場合がある。実践的には、実際のRAGパイプラインでretrieverが返す文書数に合わせるのが合理的である。retrieverがtop-5を返すなら、oracle1つ+distractor4つの構成が自然である。
部分的に可能である。HotpotQA、Natural Questions、TriviaQAなどの既存ベンチマークには質問と正解文書（oracle）のペアが含まれているため、これにdistractor文書を追加し、CoT形式の回答を再生成することでRAFT訓練データに変換できる。ただし、ドメイン固有のRAFT訓練を目的とする場合、汎用ベンチマークのデータは補助的な役割にとどまり、主要なデータセットはドメイン固有コーパスから構築する必要がある。