LLMの評価方法について、以前「デモでは動くが本番で使えない」を潰す評価設計で評価データセットの作り方と評価指標の分け方を書いた。今回はその続きで、「評価データセットを作った後、それをどう回し続けるか」という自動化の話を書く。
結論から言うと、私がやっていることは大掛かりではない。CIパイプラインに評価スクリプトを組み込み、プロンプトやモデルを変更するたびに全件を機械的に再実行する、それだけだ。ただし「機械的に再実行する」を成立させるまでの設計判断がいくつかあり、そこを飛ばすと自動化は形だけになる。
なぜ手動評価では続かないのか
評価データセットを作った直後は、誰でも真面目にチェックする。問題は2週間後、3週間後だ。
プロンプトを1行変えるたびに、評価データセット十数件〜数十件を目視で確認するのは、現実には続かない。締切が近づけば真っ先に省略されるのがこの工程で、私自身、自動化する前は「今回は明らかに良くなってるから大丈夫だろう」という感覚評価で済ませてしまうことが何度もあった。その結果、一部のケースで退行（リグレッション）が起きていることに、クライアントからの指摘で初めて気づいたこともある。
自動化の目的は精度を上げることではなく、「サボれない仕組みにする」ことに近い。人間の意志力に頼る工程は、忙しさに比例して確実に劣化する。
評価ツールは自作スクリプト＋CI、LLM-as-a-judgeもCIで回す
私が実際にやっている構成はシンプルだ。
- 評価データセット（入力・期待する出力の範囲・許容基準）をリポジトリ内にバージョン管理下で置く
- 評価スクリプトを用意し、プロンプト/モデルの設定ファイルへの変更をトリガーにCIで自動実行する
- LLMの出力を、ルールベースで判定できる項目（フォーマット、必須キーの有無、禁止語の混入など）と、LLM-as-a-judgeで判定する項目（意味的な正しさ、トーンの妥当性）に分けてスコアリングする
- スコアが閾値を下回ったケースを一覧化し、PRのコメントやSlack通知として可視化する
ポイントは、全部をLLM-as-a-judgeに丸投げしないことだ。フォーマット崩れや必須項目の欠落のようなルールベースで機械的に判定できるものは、素直に文字列処理やスキーマ検証で弾く。判定コストが安く、揺れがない分だけ信頼できる。LLM-as-a-judgeは、ルールで書き切れない「意味的にずれていないか」という部分に絞って使う。判定にLLMを使う以上、判定自体にもブレが出ることは前提として受け入れている。
「閾値を割ったら止める」の運用は現実的か
自動化を検討する際に必ず出てくる論点が、「評価スコアが閾値を割ったらデプロイを止めるべきか」だ。
私のクライアントワークでの実践では、これを機械的にブロックする運用にはしていない。理由は単純で、LLMアプリの評価は従来のユニットテストほど白黒がはっきりしないことが多く、閾値の設定自体に恣意性が残るからだ。閾値を割った変更を機械的に止めてしまうと、「本当は問題ない変更」まで足止めされ、結局CIの警告を無視する習慣がつく方が怖い。
代わりにやっているのは、退行が起きたケースを人間に見せる場所を作ることだ。CIの結果をPRに紐づけて、レビュー担当者が「このスコア低下は許容範囲か」を判断できるようにしている。自動化の役割は「判断を自動でやること」ではなく、「判断に必要な材料を毎回同じ手順で揃えること」だと捉えている。
継続コストをどう抑えるか
評価を自動化した後も、コストはゼロにならない。評価データセット自体が古くなる、LLM-as-a-judgeに使うモデルのバージョンが変わって判定基準がブレる、といったことが起きる。
私が意識しているのは、評価データセットへのケース追加を「バグ修正のたびに1件足す」というルールにしていることだ。本番で想定外の出力が見つかったら、その入力をそのまま評価データセットに追加する。これによって、評価データセットが実際に起きた問題を反映して育っていく形になり、最初に作った数十件のまま放置されることを防いでいる。
まとめ
- 手動評価は忙しさに比例して確実にサボられるため、自動化の目的は精度向上ではなく「サボれない仕組み化」にある
- ルールベースで判定できる項目とLLM-as-a-judgeで判定する項目を分け、判定コストと信頼性のバランスを取る
- 評価スコアの閾値割れを機械的なデプロイブロックにはせず、人間が判断できる材料としてPR上に可視化する運用にしている
- 本番で見つかった想定外のケースをそのつど評価データセットに追加し、データセット自体を育てる運用にしている
次回は、評価に使うLLM-as-a-judge自体の精度をどう検証しているか、という一段深い話を書く予定だ。
