RAGOps Studioとは
RAGOps Studio は、Azure AI Search の検索実験と RAG 検証をブラウザ内で行うための統合開発ツールです。検索リクエストの構築、Auto Tuning、スキルパイプライン編集、各種評価支援機能を1つの UI にまとめています。
新機能である Eval Dataset Generator は検索評価データの作成と再利用を担います。出力ファイル JSONL は Search Parameter AutoTuning 機能とスキーマ互換で、保存済みデータセットの再読込や UI 内連携も可能です。
1. Eval Dataset Generator ~ LLM による評価データセット自動生成
1.1 なぜ評価データセットが必要なのか
RAG システムの検索品質を定量的に評価するには、「どのクエリに対して、どのドキュメントが返されるべきか」を定義した評価データセットが不可欠です。しかし、この評価データセットを人手で作成するのは非常にコストが高く、検索対象のドキュメントが数千〜数万件に及ぶ場合には現実的ではありません。
Eval Dataset Generator は、Azure AI Search インデックス内の実ドキュメントから LLM を使って評価データセットを自動生成する機能です。生成されるデータセットは Search Parameter AutoTuning 互換の JSONL 形式であり、生成からパラメータ最適化まで一気通貫で実行できます。さらに、RAFT（LLM ファインチューニング） 用データセットや HyDE（ベクトル検索評価） 用仮説文章も同一パイプラインから出力可能です。
1.2 アーキテクチャ概要
Eval Dataset Generator は、以下のレイヤーで構成されています。
各モジュールの役割を以下に示します。
| モジュール | 役割 |
|---|---|
evalDatasetSampling.ts |
Index Structure Detection + Adaptive Sampling（構造検出 → 最適サンプリング） |
evalDatasetGenerator.ts |
Azure OpenAI Chat Completions 呼び出し、JSON パース、表層重複排除、JSONL 変換、RAFT CoT 生成、HyDE 仮説生成 |
evalDatasetPrompts.ts |
Classic / Ragas / Evol-Instruct / RAFT / HyDE 各モードのシステム/ユーザープロンプト構築 |
evalDatasetGrounding.ts |
Round-trip Consistency フィルター、Hard Negative Mining、Distractor 取得 |
evalDatasetEmbeddings.ts |
Azure OpenAI Embeddings によるセマンティック重複排除 |
evalDatasetRagas.ts |
Ragas 4象限シナリオプランニングと Multi-hop ペアリング |
evalDatasetEntities.ts |
LLM ベースのエンティティ抽出（Entity-KG） |
evalDatasetStyleEvolution.ts |
Style Evolution（SNS モード）— 5 種の表層劣化 |
現在の全体フロー
現行実装のパイプラインは、必須段階とオプション段階を含めると次のようになります。
GRADE パイプライン各ステップ一覧
| # | ステップ | 何をするか | 使用技術名 | コスト源 |
|---|---|---|---|---|
| 0 | Index Structure Detection | スキーマ+facetでインデックス構造を自動判定 | — | Search REST ×2 |
| 1 | Document Sampling | 判定結果に応じた多様なサンプリング | — | Search REST |
| 2 | Scenario Planning | 4象限×Persona×Style×Lengthへ割り当て | Ragas, RAGEval | ローカル計算 |
| 3 | Query Generation | Azure OpenAI JSON modeでクエリ合成 | InPars, RAGEval | LLM (生成) |
| 4 | Surface Dedup | Token Jaccard ≥ 0.85 を除外 | — (Jaccard) | ローカル計算 |
| 5 | Round-trip Consistency | 再検索でexpected_idsがtop-kに入るか検証 | Promptagator | Search REST |
| 6 | Semantic Dedup | Embedding cosineで意味重複を除外 | — (Embedding cosine) | Embeddings API |
| 7 | Difficulty Evolution | Evol-Instruct風にharder variantへ書き換え | Evol-Instruct | LLM (Judge) |
| 8 | Style Evolution (SNS) | 実ユーザ風の表層崩しを適用 | — | LLM (Judge) |
| 9 | Hard Negative Mining | top-kの非正解IDをhard_negative_idsに格納 |
DPR | Search REST |
| 10 | Relevance Grading | NDCG/XDCG互換のrelevance_gradesを付与 |
TREC / NDCG | ローカル計算 |
| 11 | RAFT mode | oracle+distractorでCoT回答を生成(Option) | RAFT | LLM (Judge) + Search REST |
| 12 | HyDE mode | 仮想回答passageをベクトル検索入力用に生成(Option) | HyDE | LLM (Judge) |
このパイプラインを、本記事では GRADE (Grounded RAG Assessment Dataset Engine) と呼びます。
この機能が重要なのは、「LLM に質問を投げてクエリを返すだけ」の機能ではなく、生成後の品質フィルター、難化、実トラフィック近似、学習向け拡張、評価向けメタデータ付与まで含む多段階パイプライン であるという点です。
なぜ GRADE か
既存の合成クエリ生成ツールの多くは「文書→LLM→質問リスト」で止まっています。しかしそれだけでは、生成したデータで何かを評価したとき、その結論は信頼できるのか？ という問いに答えられません。
GRADE が13段のパイプラインを持つのは、この問いに対する工学的な回答です。
1. 合成クエリの三大欠陥を構造で潰す
| 欠陥 | 起きること | パイプライン上の対策 |
|---|---|---|
| Self-fulfilling bias | 生成元 doc が必ず検索上位に来る前提で評価が甘くなる | Step 5 Round-trip Consistency: 現行設定で実際にtop-kに入らないクエリを棄却 |
| Distribution shift | LLM生成文はきれいすぎて実ユーザと乖離 | Step 8 SNS mode: keyword/typo/colloquial/code-switchで実トラフィックに近似 |
| Homogeneity | 同じ言い回しが何度も出て多様性がない | Step 4 Surface Dedup + Step 6 Semantic Dedup: 表層・意味の二重フィルターで圧縮 |
2. 評価用途と学習用途を1本のパイプラインで兼ねる
通常、検索評価データセットとfine-tuning用データセットは別々の工程で作ります。Eval Dataset Generatorはパイプラインの前半（Step 0〜10）で検索評価用の JSONL を作成し、後半のオプション（Step 11 RAFT / Step 12 HyDE）で学習用素材も同時に生成します（あくまで便利機能として）
- 評価用:
query+expected_ids+hard_negative_ids+relevance_grades - RAFT用:
question+context[oracle + distractors]+cot_answer - HyDE用:
query+hyde_hypothesis（vectorText入力として即座に利用可能）
「まず評価を回して改善点を見つけ、必要に応じて同じデータから学習データも取る」という一気通貫のワークフローが、追加の手作業なしに実現できます。
3. 段階的ON/OFFで費用対効果を制御できる
すべてのステップを有効にすれば最大品質のデータセットが得られますが、トークンコストもそのぶん膨らみます。このパイプラインは各段を独立にON/OFF可能に設計されています。
最小構成（LLM 1回/doc）:
Sampling → Generation → Surface Dedup → Export
推奨構成（信頼性重視）:
+ Adaptive Sampling + Grounding + Semantic Dedup + Relevance Grading
最大構成（学習データ兼用）:
+ Ragas mode + Difficulty + SNS + Hard Negative + RAFT + HyDE
最小構成なら LLM コールは文書数分だけで済み、残りはすべてローカル計算か Search REST API です。「とりあえず 10 件で試す→品質を確認→本番用に 100 件で全段 ON」という段階的スケールアップが無理なく可能です。
利用するモデルを設定できる画面を追加
ユーザーの多様なモデル利用を想定して、OpenAI, Azure OpenAI, Foundry Local, LMStudio でそれぞれホスティングしているモデルを簡単に切り替え可能です。
4. Traceability（追跡可能性）がビルトイン
合成データの品質管理で最も厄介なのは「なぜこのクエリが残ったのか / 落ちたのか」が分からなくなることです。enableTraceをONにすれば、各アイテムのライフサイクルがステップごとに記録されます。
{ "step": 3, "phase": "grounding", "action": "rejected", "detail": { "reason": "grounding", "score": 0 } }
{ "step": 6, "phase": "style-evolution", "action": "modified", "detail": { "before": "セマンティックランカーとは", "after": "セマンティックランカー って何" } }
これにより、拒否率が高すぎるときに「grounding の設定が厳しすぎるのか、生成プロンプトがインデックスと噛み合っていないのか」を切り分けられます。
5. チャンクインデックスに対する考慮
RAG 用インデックスの大多数はドキュメントをチャンク分割しています。例えば単純に先頭 N 件を取ると同一 PDF 由来のチャンクでサンプルが埋まり、生成も評価も偏ります。
Eval Dataset Generatorは:
- Adaptive Sampling: ソース単位で代表チャンクを選び多様性を保証
- Same-source pair exclusion: multi-hop生成時に同一ソース内ペアを自動除外
- Sibling-aware grounding: 兄弟チャンクを候補に含めて不当なリジェクトを回避
という 3 つの仕組みで多様なインデックス構造に対応します。
5.1. 工学的基盤：採用した先行研究と手法の解説
Eval Dataset Generator は「プロンプトを 1 本書いて LLM に投げるだけ」の単純な実装ではなく、情報検索と自然言語処理の研究で工学的に有効性が実証された手法を組み合わせて設計されています。ここでは、各手法の背景と「なぜそれが必要なのか」をわかりやすく解説します。
5.1.1. InPars / Promptagator — Few-shot によるクエリ生成
論文: Bonifacio et al., "InPars: Data Augmentation for Information Retrieval using Large Language Models", SIGIR 2022 / Dai et al., "Promptagator: Few-shot Dense Retrieval From 8 Examples", ICLR 2023
課題: IR（情報検索）モデルの学習には大量の「クエリ ↔ 関連ドキュメント」ペアが必要ですが、人手で作るのは高コストです。
解決策: LLM にドキュメントを見せて「このドキュメントに対してユーザーが検索しそうなクエリ」を生成させます。InPars は GPT-3 を使った最初の大規模実証であり、Promptagator はわずか 8 個の few-shot 例から高品質なクエリを大量生成できることを示しました。
RAGOps Studio での実装: evalDatasetPrompts.ts の buildFewShot 関数が、ユーザーが選択したクエリタイプ（factoid, how-to, comparative, yes-no）に応じて動的に 2〜5 個の few-shot 例をプロンプトに埋め込みます。
💡 ポイント: Few-shot 例がないと、LLM は汎用的で曖昧なクエリを生成しがちです。InPars の研究では、few-shot 例を加えることで生成クエリの検索適合率が 20〜40% 向上することが示されています。
5.1.2. Promptagator — Round-trip Consistency Filter
論文: Dai et al., "Promptagator", ICLR 2023
課題: LLM が生成したクエリが、本当にソースドキュメントと関連しているとは限りません。LLM はドキュメントの内容を「幻覚（ハルシネーション）」で歪めてクエリを作ることがあります。
解決策: 生成されたクエリで実際の検索エンジンを叩いて（Round-trip）、元のドキュメントが上位 k 件に返ってくるかを検証します。返ってこないクエリは、検索エンジンにとって「ソースドキュメントと結びつかない不良クエリ」であるため棄却します。
💡 ポイント: Promptagator の論文では、Consistency Filter を適用することでノイズの多い合成クエリを 15〜30% 除去でき、残ったクエリだけで学習した Retriever の精度が人手データで学習した場合と同等以上になることが報告されています。RAGOps Studio ではこのフィルターをデフォルト ON としています。
5.1.3. Ragas — 4象限シナリオによるクエリ多様性
課題: 単純な「1ドキュメント → N クエリ」の生成では、事実検索型（factoid）のクエリばかりが量産され、実際のユーザーが発する多様なクエリパターンを再現できません。
解決策: Ragas はクエリを2軸 × 2値 = 4象限に分類するタクソノミーを提案しています。
さらに、各象限のクエリに Persona（開発者、マネージャー、初心者など）、Style（web_search, chat, formal, informal）、Length（short, medium, long）の直交軸を掛け合わせることで、現実世界のクエリ分布を模倣します。
RAGOps Studio での実装: evalDatasetRagas.ts の planScenarios 関数が、ユーザー指定の分布比率を Largest-Remainder 法で整数に変換し、各スロットに Persona/Style/Length をサイクリックに割り当てます。Multi-hop スロットには findDocPairs（Token Jaccard）または findDocPairsByEntities（Entity Jaccard）でドキュメントペアが割り当てられます。
💡 ポイント: 実ユーザーのクエリは「セマンティック検索とは」（
single_specific）だけでなく、「セマンティック検索とベクトル検索の違いを教えて」（multi_specific）や「検索品質を改善する戦略を概観して」（single_abstract）など多様です。4象限の分布を制御することで、評価データセットのカバレッジの偏りを防げます。
5.1.4. Evol-Instruct — クエリの難化（Difficulty Evolution）
論文: Xu et al., "WizardLM: Empowering Large Language Models to Follow Complex Instructions", 2023
課題: LLM が自然に生成するクエリは「ドキュメントの内容をそのまま問い直す」形が多く、簡単すぎる傾向があります。本番の検索エンジンが本当に難しいクエリにも対応できるかを評価するには、難しいクエリも必要です。
解決策: Evol-Instruct は、既存の指示文（ここではクエリ）を LLM を使って段階的に難化させる手法です。具体的には以下の戦略を適用します。
| 戦略 | 例（元 → 難化後） |
|---|---|
| パラフレーズ | 「セマンティック検索とは？」→「文脈的意味に基づく検索メカニズムの動作原理は？」 |
| 否定表現 | 「ベクトル検索はどう設定する？」→「ベクトル検索を使わずに高精度な結果を得るには？」 |
| 集約 | 「RRF のスコア計算は？」→「ハイブリッド検索における全スコアリング段階の相互作用は？」 |
| 抽象化 | 「HNSW のパラメータは？」→「近似最近傍探索アルゴリズムの精度とレイテンシのトレードオフは？」 |
💡 ポイント: 難化は元ドキュメントで回答可能な範囲に制約されます。これにより「答えのない問題を作ってしまう」リスクを回避します。難化に失敗した場合は元のクエリを保持するフォールバック設計とし、評価不能なクエリの混入を防ぎます。
5.1.5. DPR — Hard Negative Mining
論文: Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020
課題: 評価データセットに「正解ドキュメント」しか含まれていないと、「似ているが正解ではないドキュメント」を正しく区別できるかを評価できません。
解決策: DPR の対比学習（Contrastive Learning）の考え方を応用し、各クエリに対して検索結果の上位に出現するが expected_ids には含まれないドキュメントをHard Negative（紛らわしい不正解）として記録します。
💡 ポイント: Hard Negative は「検索エンジンが騙されやすいドキュメント」です。これを評価データセットに含めることで、NDCG などのランキング評価指標がより鋭敏になり、パラメータチューニングの効果を正確に測定できます。
5.1.6. RAGEval — Domain Schema による生成品質向上
論文: Zhu et al., "RAGEval: Scenario Specific RAG Evaluation Dataset Generation Framework", 2024 (arXiv:2408.01262)
課題: 汎用プロンプトだけでは、ドメイン固有の専門用語や関係性を反映したクエリが生成されにくく、表面的な質問ばかりになります。
解決策: RAGEval は、ドメインのエンティティ（用語）・関係（エンティティ間のつながり）・制約（ビジネスルール） を構造化したスキーマをプロンプトに注入することで、生成されるクエリの事実性とスキーマ整合性を向上させる手法です。
RAGOps Studio での実装: UI の 3 つのテキストエリア（Entities / Relations / Constraints）で入力された DomainSchema が renderDomainSchema() 関数でプロンプト末尾に注入されます。未設定時は何も出力されず、既存のプロンプトと完全に互換です。
5.1.7. Entity-KG — 軽量ナレッジグラフによる Multi-hop ペアリング
出典: Ragas Knowledge Graph + RAGOps Studio 独自実装
課題: Multi-hop クエリ（複数ドキュメントを横断する質問）を生成するには、「関連はあるが同一ではないドキュメントのペア」を見つける必要があります。
解決策: 2段階のアプローチを採用しています。
デフォルトの Token Jaccard はLLM 呼び出し 0 回で動作するため、高速かつ低コストです。Entity-KG を有効化すると、LLM でドキュメントごとに固有名詞・専門用語を抽出し、エンティティ集合間の Jaccard でより意味的に適切なペアリングを行います。抽出に失敗した場合は Token Jaccard に自動フォールバックします。
5.1.8. NDCG / XDCG — 段階的関連度評価
出典: Microsoft Foundry RAG Evaluators, TREC 評価メトリクス
課題: 検索結果の評価では「正解か不正解か」の二値だけでなく、「どの程度関連しているか」の段階的な評価が重要です。
解決策: NDCG（Normalized Discounted Cumulative Gain）は、検索結果のランキング品質を段階的関連度スコアで評価する業界標準の指標です。RAGOps Studio では computeRelevanceGrades 関数が以下のルールで自動付与します。
| ドキュメント種別 | Relevance Grade | 意味 |
|---|---|---|
Primary Anchor（source_doc_id） |
4 | 最も関連度が高い |
Secondary（残りの expected_ids） |
2 | 副次的に関連 |
Hard Negative（hard_negative_ids） |
0 | 関連性なし |
"retrieval_ground_truth": [
{ "document_id": "doc-020", "query_relevance_label": 4 },
{ "document_id": "doc-055", "query_relevance_label": 0 }
]
意味としては、4 が最も関連度が高い正解文書、2 が補助的・部分的に関連する文書、0 が関連なしです。
💡 ポイント: この
retrieval_ground_truthフォーマットは Microsoft Foundry の Document Retrieval Evaluator（NDCG / XDCG / Max Relevance / Holes）と直接互換です。生成した JSONL をそのまま Foundry に渡して高度な評価が実行できます。
6. Style Evolution（SNS モード）
なぜクエリの表層劣化が必要なのか
LLM が生成するクエリは文法的に完璧で、語彙が整いすぎているという根本的な問題があります。現実のユーザーは以下のような「乱雑な」クエリを入力します。
| 実ユーザーの検索 | LLM が生成する検索 |
|---|---|
azure 検索 ベクトル 設定 |
Azure AI Search でベクトル検索を設定する方法は？ |
セマンティックランカーってなに |
セマンティックランカーの機能と用途を説明してください |
hnsw パラメタ efSearch |
HNSW アルゴリズムの efSearch パラメータの最適値はいくつですか？ |
AI serch hybrit search |
Azure AI Search でハイブリッド検索を実行するにはどうすればよいですか？ |
検索エンジンが整形されたクエリでしか評価されないと、実トラフィックでの品質劣化を見逃すリスクがあります。Style Evolution は、品質パイプラインの Stage ⑦ で LLM 生成クエリを意図的に「劣化」 させ、実ユーザーの表層パターンを再現します。
5 種類の劣化パターン
| Kind | 説明 | 入力例 | 出力例 |
|---|---|---|---|
keyword |
助詞・接続詞を除去してキーワード列に | ベクトル検索の設定方法は？ |
ベクトル検索 設定 方法 |
colloquial |
SNS・口語形式に変換 | セマンティック検索とは何ですか？ |
セマンティック検索ってなに |
typo |
1〜2 箇所のリアルなタイポを挿入 | hybrid search configuration |
hybrit search configration |
abbreviated |
主語・文脈語を省略して最小化 | Azure AI Search でフィルターを使う方法 |
フィルター 使い方 |
code_switch |
日英をミックスした表現に | HNSW のパラメータ設定 |
HNSW parameter設定 |
Style Evolution のトレース表示
生成結果は JSONL でダウンロード可能
GitHub