評価スコアの罠を回避せよ：AIエージェントによるテストデータ多様性（Semantic Diversity）自動評価の実践

導入部

「オフライン評価では正答率90%を超えていたのに、リリース初日から『期待した回答が返ってこない』という問い合わせが殺到している……」

RAG（検索拡張生成）システムやチャットボットの開発プロジェクトにおいて、このような状況は決して珍しくありません。開発チームはプロンプトを調整し、リトリーバー（検索器）のチューニングに奔走しますが、それでも状況が改善しないことがあります。

なぜ、このような乖離が生まれるのでしょうか。

多くの場合、根本的な原因はモデルや検索ロジックではなく、「評価に使っているテストデータそのもの」に潜んでいます。開発現場では無意識のうちに、想定しやすい質問パターンや、既存のFAQリストにあるような整った日本語表現だけをテストデータとして採用してしまいがちです。

しかし、実際のユーザーは開発者の想定を軽々と飛び越えてきます。曖昧な表現、独特な言い回し、専門用語の誤用、あるいは全く異なるコンテキストからの質問。これら「未知の多様性」に対して、用意されたテストデータセットは「均質」で「狭い」ことが多いのです。

今回は、LLMアプリケーション開発における盲点となりがちな「検証用データの品質」、特に「Semantic Diversity（意味的な多様性）」に焦点を当てます。単なるキーワードのカバレッジではなく、AIエージェントとベクトル解析を用いて、テストデータがどれだけ意味的に広がっているかを自動評価する実践的なアプローチについて解説します。

「テストデータの偏り」を解消することは、PoC（概念実証）の壁を越え、実用的なAIシステムを構築するための重要なステップです。ROI（投資対効果）を最大化する、より堅牢なAI開発の基盤を作っていきましょう。

なぜ「多様性のないデータ」での検証は無意味なのか

テストデータの多様性が欠如すると、AIシステムの評価が実質的な意味を失ってしまうメカニズムを、論理的に整理してみましょう。

高スコアの罠：過学習と似た現象

機械学習の分野には「過学習（Overfitting）」という概念が存在します。これは訓練データに過度に適応しすぎた結果、未知のデータに対応できなくなる現象です。RAGやLLMアプリケーションの評価においても、これと類似した問題が発生します。

昨今のRAGは、ハイブリッド検索やリランキングといった手法に加え、ナレッジグラフを活用したGraphRAGのようなアーキテクチャへの関心も高まっています。例えば、Amazon Bedrock Knowledge BasesにおいてAmazon Neptune Analytics連携によるGraphRAGサポートがプレビュー提供されるなど、クラウドプロバイダーを通じた高度な検索基盤の導入が進んでいます。しかし、システム側がどれほど高度化・多様化しても、評価用データが特定のパターンに偏っていれば、その真の実力は測れません。

例えば、社内規定ボットのテストデータに以下のような質問が含まれていたと仮定します。

• 「交通費の申請期限はいつですか？」
• 「交通費申請の締め切りは？」
• 「いつまでに交通費を申請すべきですか？」

これらは表面的な表現こそ異なりますが、意味的にはほぼ同一です。もしテストセット100問のうち30問がこのような「交通費の期限」に関する類似質問で占められていたら、システムがこの特定のトピックにさえ答えられれば、全体のスコア（正答率）は不当に高く算出されてしまいます。

本番環境でユーザーが「先月の電車代、まだ間に合う？」と質問した場合、システムが「申請期限」というキーワードに引きずられず、文脈を正確に理解して回答できる保証はありません。類似した質問ばかりでテストを実施しても、実運用における汎化性能を測ることは困難なのです。

Semantic Diversity（意味的多様性）の定義

ここで重要になるのが「Semantic Diversity（意味的多様性）」という概念です。これは、単に異なる単語が使われているか（Lexical Diversity）という表面的な違いではなく、ベクトル空間上でどれだけ意味が分散しているかを指します。

• 低い多様性: 質問群がベクトル空間の狭い領域に密集している状態（例：定型的なFAQ表現に偏っているケース）。
• 高い多様性: 質問群が空間全体に広く分布し、多様なトピック、意図、表現スタイルを網羅している状態。

最新の評価要件では、単純なテキスト検索の精度だけでなく、複雑な推論を要するマルチホップな質問や、曖昧なクエリに対する応答能力も厳しく問われます。テストデータに意味的な広がりが欠けていれば、高度なRAGシステムが持つ「検索（Retrieval）」と「生成（Generation）」の真の能力を評価することは不可能です。特にEmbeddingモデルを用いたベクトル検索環境において、距離が近い類似質問ばかりでテストを繰り返しても、検索ロジックの致命的な弱点（Hard Negativesの識別漏れなど）を洗い出すことはできません。

人手作成データの限界とバイアス

「様々なパターンの質問を手動で作成すれば解決するのではないか」と考える方もいるでしょう。しかし、人間がゼロからテストデータを作成するプロセスには、避けられない認知バイアスが介入します。

• 想起容易性バイアス: 自身の経験から思いつきやすい、典型的な質問ばかりを作成してしまう傾向。
• 確証バイアス: 開発した検索ロジックで正解できそうな、都合の良い質問を無意識に選択してしまう現象。
• 言語能力の限界: 作成者自身の語彙力や、特定の言い回しの癖から抜け出せない問題。

テスト担当者が精魂込めて作成したテストケース群であっても、ベクトル解析を通じて定量的に評価すると、実質的にはごく限られたパターンの繰り返しに過ぎなかったというケースは珍しくありません。さらに、システムがマルチモーダル対応や複雑なエージェント型ワークフローへと拡張し、AIが処理すべきドメインが広がるにつれて、人間の手作業だけで網羅的なテストデータを用意することは非現実的になっています。

こうした背景から、人間のバイアスを排除した客観的な指標の導入と、評価プロセスの自動化が不可欠となります。

ユースケース：金融RAGにおける「問い合わせ網羅性」の自動検証

概念論だけではイメージが湧きにくいと思いますので、具体的なユースケースで考えてみましょう。金融業界における「投資信託QAボット」の開発プロジェクトを想定します。

シナリオ：複雑な金融商品に関するQAボット

このプロジェクトでは、数千ページに及ぶ目論見書や販売用資料をナレッジベースとして、顧客からの問い合わせに回答するRAGシステムを構築しています。対象ユーザーは、投資初心者から経験豊富なデイトレーダーまで幅広く、質問のレベル感も様々です。

開発チームは、過去のコールセンターログやFAQ集を元に、約2,000件のテストデータ（質問と回答のペア）を用意しました。しかし、QAフェーズで「本当にこれで網羅できているのか？」という懸念があがりました。

課題：想定質問パターンの抜け漏れ

金融領域の難しさは、同じトピックでもユーザーの属性によって質問の「解像度」が全く異なる点にあります。

例えば「NISA（少額投資非課税制度）」に関する質問一つとっても、以下のような多様な軸が存在します。

1. 用語の正確性:
   • 「NISAの成長投資枠について」 (正確)
   • 「新しい非課税のやつ」 (曖昧)
2. 前提知識の有無:
   • 「つみたて投資枠との併用は可能ですか？」 (制度理解あり)
   • 「これって税金かからないんですか？」 (初心者)
3. 文体のトーン:
   • 「損益通算の可否をご教示ください」 (堅い)
   • 「損したらどうなんの？」 (口語)

既存の2,000件のデータを分析したところ、8割以上が「用語が正確」で「堅い文体」の質問に偏っていることが判明しました。これでは、スマホアプリから気軽に質問してくる若年層ユーザーや、用語を知らない初心者の対応精度を測ることができません。ビジネス課題の解決という観点からも、これでは不十分です。

ゴール：未知の言い回しに対する耐性評価

このプロジェクトのゴールは、テストデータの数を増やすことではなく、「データの質（多様性）」を可視化し、不足している領域（空白地帯）を埋めることです。

具体的には、以下の状態を目指します。

• テストデータが特定のトピック（例：口座開設手続き）に偏重していないか数値で判断できる。
• 「初心者視点」や「口語表現」など、ベクトル空間上で不足しているクラスタを特定できる。
• 最終的に、本番環境での「回答不能率」を最小化するための客観的な指標を持つ。

この課題解決のために導入するのが、AIエージェントによるベクトル空間分析です。

ソリューション：AIエージェントによるベクトル空間分析

具体的にどのようにしてテストデータの多様性を自動評価するのでしょうか。ソリューションの全体像とアーキテクチャについて構成を紐解きます。

アーキテクチャ概要：Embeddingとクラスタリング

基本的なアプローチは、自然言語処理（NLP）における「埋め込み表現（Embeddings）」の活用です。テキストを数百〜数千次元のベクトルに変換することで、意味的な近さを数学的な距離として計算できるようになります。

システム構成は以下の3つのモジュールで成り立ちます。

1. Vectorization Agent (ベクトル化エージェント):
   検証用データセット（質問文）をすべてEmbeddingモデルに通し、ベクトルデータに変換します。ここでは、RAG本体で使用しているモデル（例：OpenAIのEmbeddingモデルやCohere Embedなど）と同じものを使うのが一般的ですが、より細かなニュアンスを捉えるために、性能の高いモデルを評価専用に割り当てることもあります。

2. Analysis Agent (分析エージェント):
   ベクトル化されたデータの分布を分析します。ここでは主に2つの処理を行います。

   • 重複検知: コサイン類似度が高い（＝意味が酷似している）データのペアを抽出。
   • クラスタリング & 密度推定: データを意味ごとのグループ（クラスタ）に分け、それぞれの密度を計算します。特定のクラスタだけ密度が高く、他が空白地帯となっている場合、多様性が低いと判断します。

3. Visualization & Reporting (可視化・報告):
   分析結果を次元削減（t-SNEやUMAPなど）を用いて2次元または3次元マップにプロットし、直感的に理解できる形で提示します。同時に、分布に基づく「多様性スコア」を算出します。

評価フロー：データ入力からスコアリングまで

実際の処理フローは以下の手順で進行します。

1. データロード: CSVやJSON形式のテストデータを読み込む。
2. 前処理: ノイズ除去や個人情報のマスキング（必要な場合）。
3. ベクトル変換: 全質問文をベクトル化。
4. 類似度行列の計算: 全データ同士の類似度を計算し、ヒートマップのような行列を作成。
5. 多様性指標の算出: Vendi Scoreなどの数理指標を用いて、データセット全体の「意味的なリッチさ」を数値化。
6. アラート発出: 多様性スコアが閾値を下回った場合、または特定のトピックに偏りがある場合、エージェントが「『手数料』に関する質問が過多です」「『解約』に関する質問が不足しています」といった具体的な改善提案を出力。

使用する技術スタック

このソリューションは、既存のライブラリを組み合わせることで構築可能です。ただし、AIエコシステムの進化は非常に速いため、実装時にはライブラリのバージョン選定と依存関係に細心の注意を払う必要があります。

• LangChain / LlamaIndex:
  データローディングやLLMとの対話制御の中核となります。
  • LangChain: 常に最新の安定版を使用してください。特にGoogle Vertex AI関連の機能を利用する場合、従来のモジュール（ChatVertexAI等）から新しいGoogle Gen AI SDK（google-genaiパッケージ）への移行が進んでおり、古い実装は将来的に廃止される予定です。また、過去のバージョン（LangChain Core等）には深刻な脆弱性（CVE-2025-68664等）が報告されているため、セキュリティパッチが適用された最新バージョンでの運用が必須です。
  • LlamaIndex: データ構造化や検索精度の向上に強みを持ちますが、頻繁にアップデートが行われます。実装の際は必ず公式ドキュメント（docs.llamaindex.ai）で最新の仕様を確認してください。
• Vector Database (Pinecone, Weaviate, Qdrant等):
  ベクトルの格納と類似度検索の高速化を担います。小規模な検証であれば、メモリ上のNumPy配列やFAISSでも十分に機能します。
• Scikit-learn:
  クラスタリング（K-means, DBSCAN）や次元削減（PCA, t-SNE）の実装に使用します。
• OpenAI API (またはAzure OpenAI):
  Embeddingおよび分析結果の自然言語化に使用します。
  • モデル選定: ベクトル化にはOpenAIの最新Embeddingモデルを利用します。結果の解釈や改善提案の生成には、推論能力が強化されたモデルやAgent機能を活用することで、より深い洞察が得られます。ここで極めて重要な注意点として、OpenAI APIではGPT-4o等のレガシーモデルが廃止され、GPT-5.2（InstantおよびThinking）が新たな標準モデルへ移行しています。過去の実装で旧モデルのAPIエンドポイントに依存している場合、処理が停止するリスクがあります。そのため、公式ドキュメントで最新のモデル仕様を確認し、速やかに新しいモデル環境へ移行するプロセスを整えることが不可欠です。

プロジェクトマネジメントの観点から重要なのは、これを一度きりの分析で終わらせず、CI/CDパイプラインに組み込み、テストデータが更新されるたびに自動で品質チェックが実行される仕組みを構築することです。

実装ステップ：多様性スコアリングの計算ロジック

ここからは、エンジニアの方向けに、実際に多様性スコアを計算するためのロジックを解説します。数式そのものよりも、コードに落とし込む際の実践的な考え方を重視します。

Step 1: データのベクトル化と次元削減

まず、PythonとOpenAIのAPIを使ってデータをベクトル化します。

from openai import OpenAI
import numpy as np

client = OpenAI()

def get_embedding(text, model="text-embedding-3-small"):
    text = text.replace("\n", " ")
    return client.embeddings.create(input=[text], model=model).data[0].embedding

# テストデータ（質問リスト）
questions = ["NISAの始め方は？", "NISA口座開設の手順", "投資信託のリスクは？", ...]

# ベクトル化
embeddings = [get_embedding(q) for q in questions]
matrix = np.array(embeddings)

Step 2: コサイン類似度を用いた重複検知

次に、データセット内の「実質的な重複」を排除するために、類似度行列を作成します。

from sklearn.metrics.pairwise import cosine_similarity

# 類似度行列の計算
similarity_matrix = cosine_similarity(matrix)

# 閾値設定（例：0.9以上の類似度は重複とみなす）
threshold = 0.9
duplicates = []

for i in range(len(questions)):
    for j in range(i + 1, len(questions)):
        if similarity_matrix[i][j] > threshold:
            duplicates.append((questions[i], questions[j], similarity_matrix[i][j]))

print(f"重複ペア数: {len(duplicates)}")

このプロセスで抽出されたペアを確認することで、「言い回しが違うだけで中身は同じ質問」をテストデータから間引く（あるいは重み付けを下げる）ことができます。

Step 3: Vendi Score等の多様性指標の適用

重複を排除しただけでは「多様性がある」とは言えません。データが空間全体に広がっているかを測るために、Vendi Score という指標が注目されています。これは生態学における「生物多様性指数」を機械学習に応用したもので、データセット内の「実効的な種類の数」を表します。

直感的に言えば、Vendi Scoreが K であれば、そのデータセットには「意味的に独立したトピックが約 K 個含まれている」と解釈できます。

計算ロジックはカーネル行列（類似度行列）の固有値を用いますが、概念としては「類似度が高いデータ同士はまとめて1つと数え、全く異なるデータは別に数える」ようなイメージです。

# Vendi Scoreの簡易実装イメージ
def vendi_score(K):
    # Kは類似度行列（カーネル行列）をサンプル数で正規化したもの
    eigenvalues = np.linalg.eigvalsh(K)
    # 0以下の固有値をクリップ（数値誤差対策）
    eigenvalues = np.maximum(eigenvalues, 1e-10)
    
    # シャノンエントロピーの指数関数として計算
    entropy = -np.sum((eigenvalues / eigenvalues.sum()) * np.log(eigenvalues / eigenvalues.sum()))
    return np.exp(entropy)

# 行列の正規化
normalized_matrix = similarity_matrix / len(questions)
score = vendi_score(normalized_matrix)
print(f"Semantic Diversity Score (Vendi): {score:.2f}")

このスコアをKPIとして監視し、「テストデータ数は増えたのにスコアが横ばい」であれば、それは「似たようなデータばかり追加している」という警告になります。

比較検討：人手レビュー vs ルールベース vs AI自動評価

ここまでAIによる自動評価を推奨してきましたが、他の手法と比較してどのようなメリット・デメリットがあるのでしょうか。プロジェクトのROIを最大化するための導入判断として、比較表を整理します。

評価手法	コスト・工数	精度・品質	スケーラビリティ	特徴
人手レビュー	高 (比例して増加)	高 (文脈理解あり)	低 (数百件が限界)	専門家による目視確認。微妙なニュアンスや「良い質問」の判定には最適だが、数千件規模では対応が難しい。またレビュアーのバイアスが入る。
ルールベース	低	低	高	正規表現やキーワードマッチング。「特定の単語が含まれているか」は判定できるが、意味的な重複や多様性は捉えられない。
AI自動評価	中 (初期構築コスト)	中〜高	高 (無制限)	ベクトル解析による定量評価。意味的な重複検知に優れる。初期構築とAPIコストはかかるが、運用コストは低い。

精度とコストのトレードオフ

人手レビューは、初期段階の少数データ（例：ゴールデンデータセット100件）を作成する際には不可欠です。しかし、RAGの精度向上には数千件規模のテストデータが必要となるため、フェーズが進むにつれてAI自動評価への移行、あるいはハイブリッド運用が現実的な選択肢となります。

導入判断のチェックリスト

以下の項目のうち2つ以上当てはまる場合は、AIによる多様性評価の導入を検討すべきタイミングです。

• テストデータが1,000件を超えている。
• テストデータの作成者が複数人おり、品質にバラつきがある。
• 特定のトピックに関する質問ばかり追加されている気がする。
• 本番環境での「想定外の質問」による失敗が多い。

発展的活用：不足データの自動生成（Data Augmentation）への接続

評価して「多様性が低い」とわかったら、次は何をすべきでしょうか。もちろん、データを追加することです。ここでもAIエージェントが実践的に活用できます。

評価から改善へ：空白領域の埋め合わせ

ベクトル空間分析の最大の利点は、「どこにデータがないか」が座標としてわかることです。Embedding空間上の密度が低い領域（空白地帯）は、現在のテストデータセットがカバーできていない「盲点」を示しています。

この情報を利用して、LLMに新たなテストデータを生成させることができます（Synthetic Data Generation）。

シンセティックデータ生成のプロンプト設計

単純に「多様な質問を作って」と指示するのではなく、分析結果に基づいた具体的な指示を与えます。

悪いプロンプト例:

「投資信託に関する質問をもっと作ってください。」

分析結果に基づく良いプロンプト例:

「現在のデータセットには、『解約手数料』に関する質問と、『初心者特有の曖昧な表現（これって損するの？等）』が含まれる質問が不足しています。この2つの条件を満たす具体的な質問パターンを10個生成してください。」

このように、評価（Evaluation）の結果を生成（Generation）の入力としてフィードバックすることで、テストデータセットを自律的に進化させるループ（Data Flywheel）を構築できます。

品質管理のループを回す

ただし、AIが生成したデータにはハルシネーション（事実と異なる内容）が含まれるリスクがあります。そのため、生成されたデータに対しても再度ベクトル分析を行い、既存データと重複していないか、またRAGのナレッジベースに回答根拠が存在するかをチェックするプロセスが必要です。

まとめ

RAGやLLMアプリケーションの品質は、モデルの性能以上に「テストデータの質」に依存します。意味的な重複を排除し、多様性を確保することは、システムが実社会の複雑さに対応できるかを測るための重要なステップです。

本記事で解説したポイントを振り返ります。

1. スコアの乖離: テストデータの偏りは、本番環境での失敗を隠蔽する。
2. Semantic Diversity: キーワードではなく「意味空間の広がり」で多様性を定義する。
3. 自動評価の実装: Embeddingとベクトル解析（コサイン類似度、Vendi Score）を用いて定量化する。
4. 評価から生成へ: 分析で見つかった「空白地帯」をAI生成データで埋め、テストセットを進化させる。

「テストデータの多様性評価」は、まだ多くの現場で導入されていない領域です。だからこそ、ここに取り組むことで競合他社のシステムと明確な品質差をつけ、ビジネスに真の価値をもたらすAI導入を実現することができます。