カスタム LLM の QA 失敗を 7 ステップで診断する方法

リリースサイクルからのノート — 第 VI 回

スコア付き QA スイートが、あるお客様の医療 Q&A モデルにフラグを立て始めました。すべてのスライスにわたる集計品質という見出し指標が、一晩で 6 ポイント低下したのです。チームは 2 日間モデルのデバッグに費やしました。ファインチューニングを再実行しました。直前のリリースにロールバックしました。それでも数値は動きませんでした。

3 日目の朝、誰かが評価スイートがリグレッションの始まった同じ夜に更新されていたことに気づきました。3 つの小児用量プロンプトがテストセットに新しく追加されていて、モデルは学習時に小児用量を一度も見たことがありませんでした。「QA 失敗」はモデルのリグレッションではなかったのです。スライスカバレッジのイベント、つまり評価が、モデルが知っているはずのないことを尋ね始めていたのです。

当社のお客様のロールアウトを通じて、これが支配的なパターンです。「QA 失敗」アラートは症状です。原因がモデルである割合はおよそ 7 回に 1 回です。 残りの 6 回は、バグはどこかしら上流、つまり評価の設計、ジャッジのキャリブレーション、プロンプト SHA、前処理パイプライン、データセットのバージョン、または検索インデックスのいずれかにあります。これらのバグのクラスはアラートからは同一に見えます — 数値が下がった — が、それぞれ修正方法はまったく異なります。

本記事は、アラートが発火したときに当社が順番にたどる診断ツリーです。最初の 6 ステップでモデル以外の原因を排除してから、7 番目のステップでモデル自体を検討します。各ステップには、それに答える具体的な API コールまたはクエリがあります。6 つを完了する頃には、何を修正すべきかが正確にわかっているか、モデルを見る権利を獲得しているかのいずれかです。

意思決定ツリー

ツリーが逐次的なのは、各ステップが安価から高価へと並んでいるためです。ステップ 1 は評価スイートの git diff で済みますが、ステップ 7 はファインチューニングサイクルそのものです。高価な作業に 1 週間を費やす前に、6 つの安価なチェックそれぞれに 10 分を費やすのが賢明です。

ステップ 1 — 評価はこのスライスをカバーしていたか?

症状。 集計品質が低下しているが、スライス別の内訳を見ると 1 つのスライスが急落し、ほかは横ばい。あるいは — もっと紛らわしく — すべての スライスがわずかに、似たような幅で低下している。

診断。 評価スイートのマニフェスト SHA を直前のリリースと比較してください。評価スイートが変更されていて、モデルを変更していないのであれば、リグレッションは評価にあり、モデルにはありません。

# リリース間で評価スイートのマニフェスト SHA を比較
curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.eval_suite_sha256'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.eval_suite_sha256'
# 異なる? 評価が変わっています。何が追加されたかを監査してください。

修正方法。 評価スイートの変更を元に戻す(意図せぬ変更だった場合)か、新しい評価に合わせて学習カバレッジを拡大する(新しいスライスが実際の本番上の懸念事項である場合)かのいずれかです。評価カバレッジの問題に対してモデルのリグレッション修正を出荷してはいけません — モデルがこれまで得意としていた事柄に対してかえって悪化させてしまいます。

当社のパイプラインでこれがどこに隠れるか。 ステージ 1 — 登録 は、評価スイート SHA をリリースマニフェストに束縛します。上記の診断は単に 2 つのマニフェストを差分するだけです。医療 Q&A チームのバグが 2 日かかった理由は、マニフェストレベルの diff を持っていなかったためです — 彼らはリリースマニフェストではなくモデルのチェックポイントを比較していたのです。

ステップ 2 — ジャッジはこのスライスで人間にキャリブレーションされているか?

症状。 評価スイートにとって 新しい スライスがスコアが低いが、そのスライスでモデルの出力を人間がレビューすると問題ないと評価する。ジャッジはモデルが失敗していると考えるが、人間はそう思わない。

診断。 失敗しているスライス上で、LLM ジャッジの評価と少量の人間評価サンプル(50 件)との間の Spearman ρ を計算します。ρ < 0.4 であれば、ジャッジはこのスライスで人間が測定しているものを 測定していない ことになります。

curl -X POST https://api.divinci.ai/v1/judges/<judge_id>/calibrate \
  -d '{ "slice": "pediatric-oncology-dosing", "human_ratings_csv": "..." }'
# → { "spearman_rho": 0.31, "interpretation": "judge_uncalibrated_for_slice" }

修正方法。 このスライスのために別のジャッジモデルを選定するか、アービターを備えたチェーン・オブ・ジャッジを使用してください。MT-Bench^[1] によれば、GPT-4 をジャッジとした場合、平均で 80% 超の人間との合意がありますが、カテゴリー別の分散はコーディングの 86% から、ライティング・人文系の 36〜44% まで広がります。問題となるのはこの分散です。「平均では良い」は、ジャッジが誤っているスライスを覆い隠します。

当社のパイプラインでこれがどこに隠れるか。 ステージ 2 — ゲート は、スライスごとのキャリブレーション済みジャッジを要求します。AI ジャッジのキャリブレーション の記事にはその手順を記載しています。キャリブレーションステップを経ずにスライスを評価に追加した場合、構造的に信頼できないゲートが出来上がっていることになります。

ステップ 3 — プロンプトテンプレート SHA は本番と一致するか?

症状。 品質が低下しているが、model_ref と dataset_ref は変更されていない。学習に関する変更は何もない。モデルは同じモデルである。にもかかわらず。

診断。 失敗したリリースマニフェストの prompt_template_ref SHA を、直前のリリースのものと比較してください。「簡潔さを改善する」ためにシステムプロンプトに加えた 38 文字の編集が、フルリトレーニング以上に下流の挙動を変化させ得ます。

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.prompt_template_ref'
curl https://api.divinci.ai/v1/releases/rel_8f72b1 | jq '.prompt_template_ref'
# 異なる? diff を取得してください。注意深く見てください。

修正方法。 プロンプトをコードとして扱ってください。10 件のリリース失敗の記事 でダッシュボード編集の失敗モードを取り上げています — Tianpan の Semver Lie ポストモーテム^[2] は、これを 2026 年の支配的な失敗パターンと名付けています。プロンプトが変わったことを証明できれば、バグを発見したことになります。

ステップ 4 — 前処理パイプラインは本番と一致するか?

症状。 モデルはローカルで評価をパスする。同じモデルが本番で同じ評価に失敗する。同じ model_ref、同じプロンプト、同じデータセット。

診断。 本番マニフェストから preprocessing_ref SHA を取得し、評価が同じものを使用して実行されたことを確認してください。古典的なケース: 学習側ではホワイトスペースを正規化し小文字化していたが、本番ではしていなかった。評価は本番の前処理を経由していたためすべてチェックが通っていた。片方だけ前処理を更新する人が現れるまでは。

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.preprocessing_ref'
# 学習・評価ハーネスが実際に使用した前処理と比較してください。

修正方法。 前処理をバージョン付きアーティファクトとしてコンテナ化してください。マニフェストから参照してください。ゲートの前処理 SHA が本番と異なる場合はデプロイを拒否してください。

ステップ 5 — データセット SHA は本番と一致するか?

症状。 失敗したリリースのゲート評価スコアが、同じ モデルの前日のゲート評価スコアと異なる。

診断。 2 つのリリース間で dataset_version フィールドを差分してください。評価スイートは同じ名前のままだが、データセットの内容が更新され再タグ付けされていた、というケースです。同じ名前、異なる SHA、異なるスコア。

diff <(curl .../rel_a01c66 | jq '.dataset_version') \
     <(curl .../rel_8f72b1 | jq '.dataset_version')

修正方法。 データセットをコンテンツハッシュしてください。データセット名はバージョンではありません。SHA がバージョンです。

ステップ 6 — 検索インデックス SHA は本番と一致するか?

症状。 RAG ワークロードに限った話です。検索コンテキストに依存する質問で品質が低下する。直接回答型の質問は変わらない。

診断。 マニフェストから retrieval_index_ref SHA を取得してください。ゲート評価の検索インデックスと比較してください。RAG インデックスが一晩で更新され(新規取り込みラン)、ゲート評価では古い検索結果がキャッシュされていて、本番カナリアは新しい方を使用した、というケースです。

curl https://api.divinci.ai/v1/releases/rel_a01c66 | jq '.retrieval_index_ref'

修正方法。 前処理を束縛するのとまったく同じやり方で、検索インデックス SHA をマニフェストに束縛してください。AutoRAG の自動インデックス更新のサイクルがあるため、これは特に確認する価値があります — ピン止めしていない限り、インデックスは承認しようがしまいが必ず更新されます。

ステップ 7 — そしてついにモデル自体

6 ステップ進みました。評価はスライスをカバーしている。ジャッジはキャリブレーション済み。プロンプト SHA は一致。前処理は一致。データセットは一致。検索インデックスは一致。

ここで — そして今ここでだけ — モデルを見る権利を獲得したことになります。

このステップの診断は、直前のリリースに対するスライスごとの Spearman 比較で、両方のリリースを 同じ マニフェスト固定のデータセット、前処理、検索に対して評価します。算出される数値はクリーンなシグナルです: 上流の交絡因子のない、実際のスライス別リグレッションです。

curl -X POST https://api.divinci.ai/v1/releases/<failing_id>/diff-eval \
  -d '{ "baseline_release_id": "<prior_id>", "slices": ["legal-IP-licensing"] }'
# → { "spearman_rho_failing": 0.41, "spearman_rho_baseline": 0.68, "delta": -0.27 }

差分が実際のリグレッションを確認した場合、自動ロールバック が発火し(手動で発動済みでなければ)、失敗したモデルは拡張されたスライスカバレッジのコーパスに対して再学習されます。このリリースを昇格させたゲートがそもそもこのスライスを見逃していた場合、ゲートもまたバグです — リリースパイプラインから機能 4 が欠落していることになります。

分布の実際の姿

先ほど挙げた「7 回に 1 回」というフレーミングは修辞ではありません。これがお客様のロールアウト全体で当社が見ているおおよその分布です。QA アラート 7 件あたり:

最も大きな 2 つのスライスは 評価カバレッジのギャップ と ジャッジの誤キャリブレーション です。両者を合わせると QA アラートの半分を占めます。どちらもモデルの問題ではありません。両者ともモデルをどう測定するかの問題です。

これが解決できないこと

正直に述べる 3 つの制約:

この分布は当社のものであり、お客様のものではありません。 上記のパーセンテージは当社のお客様コホートと当社のパイプライン上のツールから得たものです。異なる種類のワークロード — 重いマルチモーダル、重いエージェントオーケストレーション、重い単発生成型 — を運用している場合、分布は異なって見えるでしょう。診断の順序は依然として有効ですが、各ステップの背後にある数値は当てはまりません。

ステップ 1 の「評価カバレッジのギャップ」が最も修正しにくい。 不足しているスライスを学習コーパスに追加し、そのためのキャリブレーション済みジャッジを構築し、カナリアを再実行すること自体が数週間に及ぶプロジェクトです。診断は速いが、修復はそうではありません。

実際のリグレッションがモデル以外のバグに乗ることがあります。 プロンプトドリフトと実際のモデルリグレッションの 両方 が同時に発生しているケースが最悪です。なぜなら、ステップ 3 でプロンプトドリフトを発見し、それを修正しても、アラートは再発火するからです。本記事の診断順序はそれらを処理できますが、所要時間は増えます。「バグが 2 箇所に同時に存在した」ことへの近道はありません。

FAQ

なぜ LLM は類似したプロンプトに対して異なる出力を生成するのですか?

プロンプト感受性は実在しますが、それが常に QA アラートの 原因 とは限りません — ときには上流のバグの 症状 です。診断を順に進めてください。プロンプトテンプレート SHA が一致し、前処理が一致し、データセットが一致するのであれば、その場合は確かにモデルがこのスライスで広い分散を持っており、より決定論的なデコーディングパスや別のジャッジが必要です。上流で何かが変わっているのであれば、まずそれを修正してください。

LLM のベンチマークをどのくらいの頻度で再評価すべきですか?

ベンチマークの 内容 は、本番スライスのトラフィック形状が実質的に変わるたびに再評価してください。ベンチマークの ジャッジキャリブレーション は、少なくとも四半期ごとに再評価してください — ジャッジモデルは想像以上に速くドリフトします。誤った QA アラートの最大の発生源は、18 か月前に最後に検証されたベンチマークで、本番がもう行っていないことを今も測定しているケースです。

カスタム言語モデルにおけるハルシネーションの原因は何ですか?

ハルシネーションには複数の上流原因があります — 検索の失敗(上のツリーのステップ 6)、学習カバレッジのギャップ(ステップ 1、間接的に)、デコーディングパスの問題(ステップ 7 における実際のモデル上の懸念)です。AutoRAG は、検索インデックスをリリースマニフェストに束縛しリリースごとに再ピン止めすることで、検索側の原因に対処します。残りの 2 つは、モデルの上流におけるパイプラインレベルの修正を必要とします。

学習データが問題かどうかをどう判断しますか?

失敗したリリースのデータセット SHA が、直前の良好なリリースのデータセット SHA と一致するのであれば(ツリーのステップ 5)、データは 直接の 原因ではありません。異なっていれば、見つけたことになります。より難しい問い — 「データセットは当社の本番スライスカバレッジに対して 完備 しているか?」 — がステップ 1 でテストするものです。評価には完備していても、本番トラフィックには不完備なデータセットは、スライスカバレッジの問題です。

モデル全体を再学習せずに QA 失敗を修正できますか?

はい — 7 回のうち 6 回は、修正は再学習ではありません。ツリーのステップ 1〜6 には、モデルに触れない修正方法があります: 評価を更新する、ジャッジを再校正する、プロンプト SHA を再登録する、前処理を修正する、データセットを再ピン止めする、または検索インデックスを再ピン止めする。再学習はステップ 7 で、最も高価な修正であり、実際のモデルリグレッションのために確保されています。リリースパイプラインの監査証跡があれば、モデル変更に対するのと同じプロビナンス規律でこれらの上流修正を行えます。

References

1. LLM-as-judge per-category variance. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% overall GPT-4-vs-human agreement with per-category variance from coding (86%) down to writing (36–44%). Anchor for step 2 — why judge calibration has to be measured per slice rather than assumed from a published headline number.
2. The Semver Lie. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). The dominant 2026 failure-mode writeup. Names dashboard-edit prompt drift as the most-cited cause of production LLM incidents. Anchor for step 3.
3. NIST AI RMF — Measure function. NIST AI Risk Management Framework. The "Measure" function explicitly covers benchmark-validity and evaluation-coverage as part of governance, not as a separate engineering concern. Cited as the institutional anchor for treating eval design as the first diagnostic step.
4. RAGAS — retrieval-augmented generation evaluation. Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation (arXiv:2309.15217). The reference framework for RAG-side evaluation. Anchor for step 6 — separating retrieval failures from generation failures requires a RAG-aware eval discipline.
5. Internal — root-cause distribution across customer rollouts. The percentages in the pie chart are our internal observation across Divinci customer rollouts, not from a controlled benchmark. Your distribution will vary by workload type, fine-tune cadence, and team discipline. The relative ordering (steps 1–2 dominating) is stable across the cohort we've measured; the exact percentages are not portable to your environment without your own data.
6. The four-stage release pipeline. How to Build an LLM CI/CD Pipeline With Divinci AI. Each diagnostic step in this post corresponds to a manifest field bound at Stage 1 — Register. Without the manifest discipline upstream, the diagnostic loses its grip; you can't diff what you didn't bind.

本シリーズ次回: 2026 年のカスタム LLM の自動回帰テスト。 本記事は QA アラートが発火した後の診断に関するものでした。次回は、そもそもアラートを駆動した回帰テストの規律 — 評価に何を入れるか、それを正直に保つ方法、そして回帰テストがジャッジと食い違い始めたときに何をすべきか — について述べます。