質問への回答

質問の歴史

2023-2024年に生産システムにおける大規模言語モデルの急増は、従来のテスト自動化のパラダイムにおける重大なギャップを明らかにしました。早期の導入者たちは、LLMの出力に対して正確な文字列の一致やSeleniumベースのアサーションを適用しようとしましたが、モデルの固有の変動性や言い換え能力のために壊滅的な失敗を引き起こしました。これにより、品質保証チームは、文法的な一致よりも意味的な正確性が重要であることを認識するパラダイムシフトが生じました。この質問は、特に医療や金融のような規制の厳しい業界で法的な正確性が求められる決定論的CI/CDパイプライン内で非決定論的生成システムを検証する必要性から生じました。

問題

大規模言語モデルは確率的な出力を生成するため、同一のプロンプトが意味的には同等でも、テキスト的には異なる応答を生み出すことがあります。この非決定論は、予測可能な出力に依存する従来のアサーションベースのテストフレームワークを壊します。さらに、幻覚—事実とは異なる声明が真実として提示される—は、しばしば文法的に整合性があり、文脈的にも妥当であるため、ユニークな検出の課題をもたらします。標準のピクセルパーフェクトや完全一致の検証戦略では、許容される言い換えと危険な作り話を区別できません。したがって、オートメーションは意味的な意味を理解し、非構造化テキストから構造的な主張を抽出し、展開ゲートに必要な冪等で繰り返し可能な実行を維持しながら、グラウンドトゥルース知識ベースと照合する必要があります。

解決策

記号抽出と神経評価を組み合わせたハイブリッド検証フレームワークを設計します。まず、テスト実行間で決定論的な動作を確保するために、温度=0の強制とRedisを使用したセマンティックキャッシングを実装します。次に、spaCyやBERTモデルを用いた固有表現認識を使用して、LLM出力から事実の三重項を抽出します。次に、グラウンドトゥルースを含む構造的な知識グラフ（例：Neo4j）に対して、これらの抽出された主張を検証します。数値値に対しては許容範囲に基づく比較を使用し、カテゴリデータに対しては完全一致を使用します。次に、主観的な品質評価のためにJSONスキーマ制約を用いたLLM-as-a-Judgeのフォールバックを実装します。最後に、再試行ロジックと詳細なテレメトリを持つpytestフィクスチャでこのパイプラインをラップして、モデルドリフトとコードのリグレッションを分離します。

import pytest
import spacy
from knowledge_graph import verify_claim  # 仮想KGクライアント

nlp = spacy.load("en_core_web_sm")

def extract_claims(text):
    doc = nlp(text)
    claims = []
    for ent in doc.ents:
        if ent.label_ in ["MONEY", "PERCENT"]:
            claims.append({"type": ent.label_, "value": ent.text, "context": ent.sent.text})
    return claims

def test_llm_hallucination():
    prompt = "プレミアム貯蓄のAPYは何ですか？"
    response = llm_client.generate(prompt, temperature=0.0)
    
    claims = extract_claims(response)
    for claim in claims:
        if claim["type"] == "PERCENT":
            is_valid = verify_claim(
                product="プレミアム貯蓄",
                attribute="APY",
                value=claim["value"],
                tolerance=0.1
            )
            assert is_valid, f"幻覚が検出されました: {claim['value']}"

実生活からの状況

中規模のフィンテック企業は、ローン商品の金利に関する質問に答えるRAGベースのカスタマーサポートチャットボットを展開しました。ベータテスト中、LLMは「ゴールドローンのAPRは何ですか？」に「5.5%」と正しく回答しましたが、別のケースでは「クレジットチェックなしで4.9%」と幻覚しました。知識ベースには700以上のクレジットスコア要件が明確に記載されていました。従来のAPI契約テストはエンドポイントの可用性を確認しましたが、生成された財務アドバイスの意味的な正確性を検証するメカニズムはありませんでした。チームはモデルが公式な製品データベースに存在しない金利や条件を生成した場合に展開を防ぐ自動化されたゲートが必要でした。

解決策1: 正規表現を用いたキーワードベースの検証

チームは最初にPythonの正規表現パターンを実装して金額と割合を抽出し、これらの値が製品カタログのどこかに存在するかをチェックしました。

長所: reモジュールを使用して簡単に実装でき、100ms未満で迅速に実行され、決定論的な動作を実現。

短所: このアプローチは高い偽陽性率に苦しんでおり、「0%導入APR」と言及する有効な応答をフラグ付けしました。なぜならその特定の文字列が標準レートテーブルには存在しなかったからです。また、承認された数値を誤った文脈で使用した幻覚も検出できませんでした（例: クレジットカード製品の金利を示すモーゲージレートを述べる）。

解決策2: 承認済み文書に対する埋め込み類似度

彼らはLLMの応答と公式な製品文書のベクトル化されたバージョンとの間のコサイン類似度を計算しました。類似度が0.85を超えればテストが通過しました。

長所: 言い換えや同義語の使用に対して堅牢で、低いメンテナンスのオーバーヘッドがあり、文字列一致よりも意味的なニュアンスを捉えました。

短所: 数値の幻覚は検出されず、「5.5% APR」と「4.9% APR」がほぼ同一の埋め込みを持ち、物質的に異なる金融用語を表しているにもかかわらず、検出されませんでした。埋め込み計算の非決定論的な性質も、CI/CD内で不安定なテストを引き起こしました。

解決策3: 知識グラフ検証による構造的主張抽出（選択された）

チームはspaCyパイプラインを実装してエンティティと関係を抽出し、次に各主張をグラウンドトゥルースに対してNeo4j知識グラフにクエリしました。数値の主張は許容範囲（±0.01%）を使用し、カテゴリーデータは完全一致を必要としました。

長所: フィールドレベルでの事実誤りの正確な検出、言語的変動に対する免疫、導入ゲートに適した決定論的な実行。システムは「2.5% APY」（正しい）と「2.4% APY」（幻覚）を区別できましたが、埋め込みの類似度ではできませんでした。

短所: NERモデルと知識グラフスキーマの維持が必要な高い初期設定コスト、またグラウンドトゥルースデータの継続的なキュレーションも伴います。

チームは金融規制が広告された金利に絶対的な精度を要求するため、解決策3を選択しました。選択されたアーキテクチャは、フラクタルを排除するために温度=0でRedisキャッシングを使用し、あいまいな質的評価のためにLLM-as-a-Judgeをのみ使用しました。

結果として、運用における幻覚の逃避が94%減少し、事実誤りを導入する展開を自動的にブロックできるCI/CDパイプラインが確立されました。偽陽性率は35%（キーワードマッチング時）から2%に低下し、テスト実行時間は、知識グラフクエリの積極的キャッシングにより、会話のターンごとに3秒未満に留まりました。

候補者がしばしば見逃すこと

気温がゼロの場合、LLMの出力における非決定性をどのように処理しますか。しかし、異なるGPUアーキテクチャ間のハードウェアレベルの浮動小数点の違いがトークン確率分布の発散を引き起こすことがありますか？

温度=0であっても、CUDAの最適化やGPUドライバーの違いがソフトマックス計算に極小の変動をもたらし、時折、低確率の決定境界で異なるトークン選択が発生することがあります。決定論的なCI/CD実行を保証するために、プロンプトと文脈のSHA-256ハッシュをキーとしたRedisを使用したセマンティックキャッシングを実装します。最初の実行はモデルを呼び出し、応答をキャッシュします。その後、同一のプロンプトはキャッシュされた値を返します。 Alternatively, use response canonicalization by lemmatizing outputs and replacing entities with canonical IDs before comparison. 重要なテストにはself-consistency votingを使用します。プロンプトを5回実行し、応答を意味的な類似度でクラスタリングし、過半数のクラスタをそのテストセッションの正典の真実と見なします。

なぜ二次のLLMを使用して主LLMの出力を評価することが自動テストにとって問題であり、評価者の不整合のリスクをどのように軽減しますか？

LLMを評価者として使用することは、メタフレア不安定性を引き起こし、テストが製品の欠陥ではなく、評価者の幻覚のために失敗する可能性があります。評価者が異なる実行で基準を不安定に適用したり、評価ルーブリックを幻覚したりする場合があり、両方のシステムが一緒に幻覚するという循環的な依存関係が生じる可能性があります。リスクを軽減するために、評価者をJSONスキーマや関数呼び出しを使用して構造化された出力に制約し、オープンエンドな推論ではなくブール値やカテゴリ応答を強制します。明示的でバージョン管理されたルーブリックに基づいて評価を実施します。重みを更新するプロバイダーによるドリフトを防ぐために評価者モデルをバージョンロックし、人間が確認した評価の「ゴールデンデータセット」を維持して評価者の正確性を継続的に監視します。

幻覚（LLMが事実を発明すること）と古い文脈（RAGシステムが古い文書を取得すること）をどのように区別し、その区別がテスト自動化にとってなぜ重要か？

候補者はしばしば生成検証と取得検証を混同します。RAGパイプラインが「APRが5%」と述べている2022年の文書を取得し、2024年のグラウンドトゥルースが「6%」である場合、LLMが「5%」を正確に引用することは幻覚ではありません。悪いデータを正確に使用しています。自動化は、まず取得された文書を真実の源と対照させて検証し、その後、LLMの提供されたコンテキストに対する遵守を検証することで、パイプラインの境界をテストする必要があります。各主張に対してLLMにソース文書IDを引用するよう促すattribution testingを実装し、その後、これらのIDがリトリーブセットに存在し、主張された事実を含んでいることを検証します。これにより、失敗が取得の衰退や生成の幻覚から発生するかを特定でき、正確な是正が可能になります。