GitHub ActionsによるLLM-as-a-Judgeの自動化：デプロイ前にAIの不具合を未然に防ぐ – ITFROMZERO

Table of Contents

従来のユニットテストがAIに対して無力な理由

午前2時、システムのアラート通知で電話が鳴り響きました。会社のRAGチャットボットが突然、業務相談から「料理教室」へと「転職」してしまったのです。原因は単純でした。あるエンジニアが親しみやすさを出すためにプロンプトを変更し、手動で数問テストして問題なさそうだったので、そのまま本番環境にマージしてしまったのです。

問題は、LLMが非決定的（non-deterministic）であることです。同じ質問でも、AIは毎回異なる回答を返します。従来の assert response == "expected" のようなテストコードは、AIが句読点一つまで全く同じ回答を返すことが稀であるため、全く役に立ちません。意味を理解できる高度な自動評価プロセスがなければ、AIアプリのデプロイはユーザー体験を賭けた「おみくじ」のようなものになってしまいます。

現在のLLMテストにおける3つのアプローチ

この課題を解決するために, 私はトレードオフを考慮した3つの一般的な手法を検討しました。

1. ルールベースのテスト (Rule-based)

この手法では、Regex（正規表現）やキーワードチェックを使用します。実行速度が速く、コストもほぼかかりません。しかし、回答のトーン（Tone of Voice）が適切か、ハルシネーション（もっともらしい嘘）が含まれていないかを判断することはできません。例えば、200文字の文章が要点を正しくまとめているかをRegexで検証することは不可能です。

2. 手動評価 (Human-in-the-loop)

人間が直接採点するため、精度の面では「ゴールドスタンダード」です。しかし、プロジェクトのスケールにおいては大きな障害となります。システムプロンプトを一行変更するたびに、1,000件の回答をチェックし続ける忍耐力を持つ人はいないでしょう。

3. LLM-as-a-Judge (AIによるAIの採点)

GPT-4oやClaude 3.5 Sonnetのような強力なモデルを「試験官」として使い、小規模なモデルを採点させる手法です。評価モデルは具体的な評価基準（ルーブリック）に基づいて判断します。これは速度、コスト、信頼性のバランスが最も優れた選択肢です。

評価基準	Rule-based	Human-in-the-loop	LLM-as-a-Judge
速度	ほぼ瞬時	数時間〜数日	1 – 2 分
コスト	~$0	非常に高価（開発者の人件費）	中程度 (~$0.1 – $0.5/test)
柔軟性	低い	非常に高い	高い

GitHub Actionsで「クオリティゲート」を構築する

CI/CDにLLM-as-a-Judgeを導入することで、リリースへの自信が深まります。プルリクエスト（PR）が作成されるたびに、システムは標準テストケース（Golden Dataset）を実行します。平均品質スコアがしきい値（例：7/10）を下回った場合、GitHubはコードのマージをブロックします。

ステップ1：評価スクリプト（evaluator.py）の作成

単にAIに採点を依頼するのではなく、プロンプト内でChain-of-Thought（思考の連鎖）テクニックを使用し、最終的なスコアを出す前に評価モデルに理由を説明させます。これにより、デバッグが格段に容易になります。

import os
from openai import OpenAI

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

def judge_response(input_text, context, ai_response):
    prompt = f"""
    あなたはAI品質保証のエキスパートです。コンテキストに基づいて回答を評価してください。
    
    [コンテキスト]: {context}
    [質問]: {input_text}
    [AIの回答]: {ai_response}
    
    採点基準 (0-10):
    - 0: 完全に誤っている、または情報を捏造している。
    - 5: 主旨は合っているが、重要な詳細が欠けている。
    - 10: 正確かつ網羅的で、プロフェッショナルな文章である。
    
    JSON形式で返答してください: {{"reason": "...", "score": 10}}
    """
    
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        response_format={ "type": "json_object" }
    )
    # 結果を処理してスコアを返すロジック
    return score

ステップ2：GitHub Actionsによる自動化

.github/workflows/llm_eval.yml ファイルを設定し、新しいコードがプッシュされるたびにワークフローが自動的に起動するようにします。最新のライブラリを活用するため、Python 3.10以降の使用を推奨します。

name: LLM Quality Gate
on:
  pull_request:
    branches: [ main ]

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: pip install openai
      - name: Run Evaluation
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: python evaluator.py

コストを最適化するための実践的な経験

導入当初、テストを過剰に実行してしまい、一晩で50ドル近く費やしてしまったことがあります。以下は、私が行ったコストを最適化するための実践的な経験です。

Golden Dataset of 厳選: データベース全体をテストするのではなく、エッジケースを代表する最も「厄介な」質問30〜50個に絞り込みます。
評価モデルの階層化: 単純なタスクの採点にはGPT-4o-miniを使用し、複雑なロジックが必要なタスクにのみGPT-4oを使用します。これにより、APIコストを80%削減できます。
無駄なテストの防止: READMEやドキュメントのみを修正した場合は、GitHub Actionsの paths-ignore を使用してAIテストが走らないように設定します。

結びに代えて

このプロセスを導入してから、深夜の緊急電話は激減しました。チャットボットのロジックを更新するたびに不安になることもありません。LLM-as-a-Judgeは人間を完全に置き換えるものではありませんが、不具合が実際のユーザーに届く前に「初歩的なミス」を取り除くための非常に効果的なフィルターになります。

AIが顧客に「デタラメ」を言い始めてから対策を考えるのでは遅すぎます。開発の初日から、自動評価のフレームワークを構築しましょう。