LLM 評価のブレを多層的に抑える ── スコアが信頼できる数字になるまで
AI に採点させるとき、1 回の採点では誤差か実差か区別できない。繰り返し採点・G-Eval 確率加重・ペアワイズ順序反転・ブートストラップ信頼区間・BH 多重比較補正を組み合わせ、LLM 評価のブレを多層的に抑える設計を整理します。
非決定的な LLM 出力をどうテストするか。ゴールデンデータ・プロビナンス追跡・品質ゲート・Judge 設計など、実装に根ざした品質保証パターンを一筋で整理する連作。
全 8 記事 · この順で読むことをおすすめします
AI に採点させるとき、1 回の採点では誤差か実差か区別できない。繰り返し採点・G-Eval 確率加重・ペアワイズ順序反転・ブートストラップ信頼区間・BH 多重比較補正を組み合わせ、LLM 評価のブレを多層的に抑える設計を整理します。
Stage 1/Stage 2 の品質ゲートを通過しても、それだけではリリース判断に足りない。ハルシネーション・法的配慮・品質改善の 3 シグナルを統合し、LLM を呼ばずに最終判定する上位ゲートの設計を整理します。
「前より良くなったか」を人手に頼らず AI に採点させるとき、一回の採点では誤差か実差か区別できない。絶対評価とペアワイズを組み合わせ、繰り返し採点で信頼区間を出す設計を整理します。
LLM アプリのテストケースを手書きするとすぐ頭打ちになる。入力条件の組み合わせをマトリクスで定義し、LLM にテストデータを生成させてカバレッジを体系的に管理する方法を整理します。
LLM 出力の評価を「LLM による意味判定」「定量メトリクス」「ドメイン分類器」の三軸に分け、統一インターフェースで束ねる設計パターン。preference leakage を避けるモデル分離の話も含めて整理します。
LLM 出力の品質基準には「絶対に許せない最低条件」と「以前より悪くなっていないか」の二種類がある。この二つを分離した品質ゲートを設計し、CI に組み込む方法を整理します。
先週のプロンプトで生成した結果を今日の基準で評価しても意味がない。入力とプロンプトのハッシュを結果ファイルに埋め込み「この結果は今のコードで作られたか」を機械的に判定する手法を解説します。
LLM の出力は非決定的でユニットテストが刺さらない。承認済み出力を「ゴールデンデータ」として git 管理し、プロンプト変更による意図しない出力変化を検出する設計パターンを方法論として整理します。