【RAG・ナレッジマイニング・FAQチャット】「検証用・テスト用データが足らない」問題を寝てる間に解決する
はじめに
RAGやナレッジマイニングやFAQチャットの検証では、
「検証用・テストデータをどう集めるか」がよく話題になります。
地味に開発の足止めになります。
検証したいのに
著作権や機密性のない検証用データを用意すること自体が難しい・・・！
一方で、公開データやサンプル文書は、
実運用とはあまりにもかけ離れている。
結果として、
- 検証が始められない
- 仕方なく「それっぽいデータ」で済ませる
- 評価結果に自信が持てない
という状況に陥りがちです。
この記事では、この
「検証用データが存在しない」という根本的な問題を整理し、
それをどうやって解消したのかを紹介します。
RAG検証で本当に足りていないもの
RAGの検証というと、次のような話題が先に出がちです。
- どのLLMを使うか
- ベクトルDBは何にするか
- 検索アルゴリズムやRerankはどうするか
しかし多くのケースで、問題はそこではありません。
足りていないのは「検証に耐えるテストデータ」
しかもそれは、
「量が足りない」という話ではなく、
- リスクなく安全に使える
- 実運用を想定している
- 評価ができる
という条件を満たしたデータが存在しない、という意味です。
なぜテスト用データが毎回足りなくなるのか
1. 本番データは使えない
RAGの対象になるデータは、たいてい次のどれかです。
- 社内規程
- 製品マニュアル
- 手順書
- FAQ
- 問い合わせ履歴
これらはほぼ確実に、
- 機密情報を含む
- 個人情報を含む
- 社外に出せない
という制約があります。
その結果、検証用には
「本番とは別のデータ」を用意する必要が出てきます。
2. きれいすぎるデータでは検証にならない
よくある検証用データは、
- 教科書的に整理されたPDF
- 完璧に構造化されたFAQ
- ノイズのない文章
といったものです。
しかし実運用では、
- 表記揺れ
- 曖昧な言い回し
- 情報の重複や矛盾
- 古い情報と新しい情報の混在
- 専門用語、専門的要素
が必ず発生します。
きれいなデータでうまくいっても、
本番で同じ結果になるとは限りません。
3. 検証したい観点ごとに必要なデータが違う
RAGで検証したい内容は多岐にわたります。
| 検証観点 | 必要なデータの特徴 |
|---|---|
| 検索精度 | 言い換え・類似表現が多い |
| Chunk設計 | 長文・構造が崩れた文章 |
| 再ランキング | 微妙に違う正解候補 |
| ハルシネーション耐性 | 情報欠落・未記載 |
| 更新耐性 | 旧版・新版の混在 |
1つのデータセットで全部を検証することはできません。
この問題の正体
ここまでをまとめると、問題の正体はこうなります。
RAGは技術検証のはずなのに、
実態は「データ設計力」を試されている
- どんな失敗を再現したいのか
- 何を評価したいのか
- どう比較したいのか
これらをデータとして表現できていないことが、
検証が進まない最大の原因です。
同じ課題感を抱えるシーン
この問題は、特定の業界や規模に限りません。
- 生成AIのPoCを短期間で回したい
- 社内ナレッジ検索を刷新したい
- カスタマーサポートをRAGで自動化したい
- SI・受託開発で顧客データが使えない
- 内製AIチームを立ち上げたばかり
どのシーンでも、
最初につまずくのは「安全に使える検証データがない」ことです。
そこで「寝てる間に解決する」仕組みを作った
この問題に何度もぶつかり、
テスト用PDFを自動生成するツールを作りました。
重要なのは、
単にPDFを生成することではありません。
システムの構成
チャットUI(React)
ヒアリングエージェント(GPT4o)
チャット形式でユーザーが必用とするデータがどんなものかヒアリングする
ドキュメントエージェント(GPT5.1)
ヒアリングエージェントがヒアリングした情報をもとに
ドキュメントデータを作成する
リストUI
データギャラリー
自身が作成したデータや誰かが作成したデータがリスト表示されます。
わざわざ作らなくても使えそうなデータがあれば選んでダウンロード可能です。
プレビューUI
データギャラリー内のファイル名をクリックするとドキュメントのプレビュー表示が可能です。
機能詳細
AIエージェントが先にヒアリングする
このツールでは、まずAIエージェントがヒアリングを行います。
- 対象ドメイン（製品マニュアル／社内規則など）
- 想定ユーザー（現場／管理部門／顧客）
- 想定される質問タイプ（手順、例外、禁止、トラブル）
- 入れたい「汚さ」（表記揺れ、矛盾、版違い）
- 評価したい観点（検索精度、根拠提示、未記載対応）
検証目的そのものを、先に言語化します。
条件が決まったら、あとは放置
ヒアリングが終わったら、
あとは生成を実行するだけです。
- 夜に実行して寝る
- 翌朝には
- 製品マニュアル風PDF
- 社内規程風PDF
- 旧版・新版が混在した文書
が大量に出来上がっています。
人が手でデータを作る工程はありません。
実際の画面
左：エージェントウィンドウ
どんなデータが欲しいか伝えると、作成するデータを提案してくれるので
合意すればすぐにデータの作成に入ります。
右：データギャラリー
これまでに作成したデータ や 誰かが作成したデータが一覧で表示されるので
エージェントがデータを作るのを待たずにすぐにデータを入手することが可能。
プレビュー機能
データギャラリーでファイル名をクリックすると
プレビュー表示可能。
ダウンロードする前にどんな内容のデータなのか確認が可能。
今後追加したい機能
データの中に図を入れる機能
当初は、Dall-eを使用してドキュメント内に絵図を入れる機能を当初入れてたのですが
ドキュメントの作成にあまりにも時間がかかるため機能から削除。
作成したPDFの本文の内容を見ながら
必要最低限の絵図を判断する等の制御を入れて、Dall-eの使用を最低限に抑えれば実用可能かな？
データギャラリーの機能改善
ギャラリー内を検索する機能
各データをカテゴリ別に整理してデータを探しやすくする機能
何が変わったか
この仕組みを使うようになって、明確に変わりました。
- PoCの立ち上げが速くなった
- 検証結果に再現性が出た
- Chunk設計や検索方式の差が見える
- データ作りが属人化しなくなった
何より、
「今日はデータ作りで終わった」
という日が消えました。
まとめ
RAGやナレッジマイニングでは、
- モデル
- 検索基盤
- ベクトルDB
よりも前に、
「検証用データをどう用意するか」
を決めないと、検証は前に進みません。
そして多くの場合、
その壁はテストデータ以前の「安全に使える元データがない」ことです。
このツールは、
RAG検証で必ず出てくるその壁を、
寝ている間に一つ片付けるための仕組みです。
同じところで詰まっている人の参考になれば幸いです。