Posted inAI

「雰囲気で確認」するのはもうやめよう：DeepEvalによるプロンプト評価の実践ガイド

AI tutorial - IT technology blog
AI tutorial - IT technology blog

プロンプトエンジニアリングにおける「雰囲気チェック」の問題点

プロンプトを3時間かけて磨き上げ、完璧だと思ったとします。最初の5つのテストケースは完璧にこなしたので、本番環境にデプロイしました。しかし、51人目のユーザーが少し異なる質問をした途端、ボットは存在しない割引情報のハルシネーション（もっともらしい嘘）を生成し始めます。そのエッジケースを修正したところで、今度は他の3つの機能が壊れていることに気づくのです。

ソフトウェアエンジニアは何十年も前に、ユニットテストによってこのデグレード（退行）の問題を解決しました。しかし、AI開発においては、多くのチームが依然として「雰囲気チェック」に頼っています。つまり、10〜20件のレスポンスを手動で確認し、うまくいくことを祈るという手法です。これではスケールしません。LLMは非決定的です。システムプロンプトを一文字変えるだけで、エッジケースの20%で出力の質が劇的に変わる可能性があります。安定したAIツールを構築するには、感情ではなくデータで品質を定量化する必要があります。

自動評価をマスターすることは、シニアAIエンジニアと「試行錯誤」の段階で立ち止まっているエンジニアを分ける境界線です。これは、ステークホルダーが本当に信頼できるシステムをデプロイするための唯一の方法です。

LLM-as-a-Judge（評価者としてのLLM）への移行

単一の「正解」がないテキスト文字列をどのようにテストすればよいでしょうか？DeepEvalは、「LLM-as-a-judge」パターンを使用してこれを解決します。GPT-4oのようなより高性能なモデルに重労働を委任し、特定の測定可能なメトリクスに基づいてアプリケーションの出力をスコアリングさせます。

正確な文字列の一致を確認する代わりに、意味的な意図を測定します：

  • Faithfulness（忠実性）: 回答は取得されたコンテキストに厳密に従っているか？
  • Answer Relevancy（回答の関連性）: レスポンスはユーザー의具体的な問題を実際に解決しているか？
  • Hallucination（ハルシネーション）: モデルはソースデータに存在しない事実を捏造していないか？

DeepEvalはPytestに直接プラグインできます。つまり、AIのテストを標準的なPythonアプリケーションのロジックのすぐ隣に配置できるのです。

環境のセットアップ

インストールは非常に簡単です。評価者（Judge）が結果を評価するために「考える」必要があるため、OpenAIやAnthropicなどのプロバイダーからのAPIキーが必要です。

pip install deepeval pytest

開始するには環境変数を設定します：

export OPENAI_API_KEY="your_api_key_here"

ハンズオン：初めてのプロンプトユニットテストの作成

クラウドホスティングプロバイダーのサポートボットを構築していると想像してください。ユーザーが料金について尋ねた際、ボットが存在しない「50%割引」を約束しないことを保証する必要があります。

test_chatbot.pyという名前のファイルを作成します。ここでは、モデルの出力と「正解（グラウンドトゥルース）」、つまり取得されたコンテキストを比較するシナリオを定義します。

import pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

def test_pricing_response():
    # 1. シナリオの定義
    input_query = "Proプランの料金はいくらですか？"
    actual_output = "Proプランは月額20ドルで、無制限の帯域幅が含まれています。"
    retrieval_context = [
        "Proプランの価格は月額29ドルです。",
        "Proプランには1TBの帯域幅が含まれており、無制限ではありません。"
    ]

    # 2. しきい値0.7でメトリクスを設定
    # この値より低いスコアはテスト失敗となります。
    relevancy_metric = AnswerRelevancyMetric(threshold=0.7)
    faithfulness_metric = FaithfulnessMetric(threshold=0.7)

    # 3. テストケースの作成
    test_case = LLMTestCase(
        input=input_query,
        actual_output=actual_output,
        retrieval_context=retrieval_context
    )

    # 4. テストの検証（Assert）
    assert_test(test_case, [relevancy_metric, faithfulness_metric])

内部では何が起きているのか？

このスニペットでは、あえてactual_outputに誤りを含めました。29ドルではなく20ドル、1TBではなく「無制限」としています。テストを実行すると、FaithfulnessMetricがこの矛盾を指摘します。単に失敗するだけでなく、なぜ論理が破綻したのかを正確に説明してくれます。

テストの実行

ターミナルでコマンドを1つ入力するだけで評価を開始できます：

deepeval test run test_chatbot.py

結果は即座に、かつ明確に表示されます。各メトリクススコアが色分けされて表示されます。テストが失敗した場合は、「Reason（理由）」フィールドが表示されます。例えば、「出力は20ドルの価格を主張していますが、コンテキストには明示的に29ドルと記載されています」といった具合です。

ハルシネーションを早期に食い止める

ハルシネーションは、本番環境のRAGパイプラインにおける最大の障害です。DeepEvalには、単純な単語一致チェックよりもはるかに堅牢な専用のHallucinationMetricが含まれています。これは、モデルがナレッジベースに裏付けられていない主張を生成しているかどうかをチェックします。

from deepeval.metrics import HallucinationMetric

def test_no_hallucination():
    metric = HallucinationMetric(threshold=0.5)
    test_case = LLMTestCase(
        input="返金ポリシーはどうなっていますか？",
        actual_output="90日以内であれば返金可能です。",
        context=["お客様は購入後30日以内であれば返金を受ける権利があります。"]
    )
    assert_test(test_case, [metric])

DevOpsへの統合：実践的なワークフロー

自動化は継続的に行われてこそ価値があります。プロトタイプからプロダクション級のシステムへ移行するには、これらのチェックをCI/CDパイプラインに統合しましょう。推奨されるワークフローは以下の通りです：

  1. 「ゴールデンデータセット」の構築： 最も一般的なユーザーの質問や既知のエッジケースをカバーする、優先度の高いテストケースを50〜100件厳選します。
  2. マージ前のゲート設定： すべてのプルリクエスト（Pull Request）で、これらのテストのサブセットを実行します。プロンプトの変更によって忠実性スコアが低下した場合、マージを自動的にブロックします。
  3. プロンプトのバージョン管理： プロンプトをコードと同じように扱います。バージョンを更新する際は、フルスイートを実行して、レスポンスの質にデグレードがないことを確認します。

コストについて一言：GPT-4oを評価者として1,000件のテストケースを評価すると、高額になる可能性があります。大量のテストを行う場合は、GPT-4o-miniに切り替えましょう。非常に安価（フルスイートで0.10ドル未満が多い）でありながら、評価者としての精度も驚くほど高いです。

まとめ

手動テストは、AI開発の生産性を阻害する隠れたボトルネックです。DeepEvalのようなフレームワークを採用することで、プロンプトが機能するかどうかを「推測」するのをやめ、どのように機能しているかを正確に「把握」できるようになります。ハルシネーションがユーザーに届く前に検知し、改善の明確な監査証跡を構築しましょう。長期的に使い続けられるAIツールを真剣に構築したいのであれば、今すぐ「雰囲気チェック」をやめてユニットテストを始めてください。

Share:
Tags: