品質ゲートを通過した後の問い

Stage 1 / Stage 2 の品質ゲートは「出力が最低条件を満たすか」「以前より悪くなっていないか」を見ます。しかしこの 2 つをクリアしても、「リリースしてよいか」には答えられません。

品質ゲートは欠陥の有無を測るものですが、リリース判断にはさらに 2 つの問いが必要です。ハルシネーションや法的リスクはゼロか？ そして有意な改善があるか？

この 3 つの問いにまとめて答えるのが release-gate（リリースゲート）です。

3 シグナルの構造

シグナル 成果物 CSV 合格条件
① ハルシネーション judge_LLMJudge.csv predicted_label に NG が 0 件
② 法的配慮 judge_BayesJudge.csv predicted_label に NG が 0 件
③ 品質スコア quality_eval.csv 有意な改善軸が 1 つ以上 ＆ 有意な悪化軸が 0

①② は3 種の Judge パターンで生成した CSV です。③ はquality-eval が生成した採点結果です。release-gate はこの 3 つの CSV を読み込んで判定します。

設計思想：LLM を呼ばない

リリースゲートの判定フェーズでは LLM を一切呼びません。事前に生成された CSV を読むだけです。

「成果物を作るフェーズ」と「判定するフェーズ」を分離することで、判定が高速・冪等になります。同じ CSV があれば何度実行しても同じ結果が返ります。また判定ロジックが確率的でないため、CI でも安定して使えます。

注意点として、判定前に各 CSV を必ず最新化することが鉄則です。CSV は追記式のため、古い実行の行が残っていると判定が古いデータに汚染されます。

①② は絶対条件、③ は統計的改善

①② の合格条件は「NG が 0 件」という絶対条件です。ハルシネーションや法的リスクが 1 件でも残っていれば即ブロックします。「だいたい良い」では足りません。

③ は「有意な悪化軸が 0」かつ「有意な改善軸が 1 つ以上」という条件です。有意かどうかは quality-eval の信頼区間で判定されます。--repeat 1（既定値）では信頼区間が計算できないため常にブロックされます。--repeat N（N >= 2）を指定することが必須です。

実行フロー

# ① 成果物を最新化する（この順序は問わない）
docker compose run --rm sim --judge llm        # → judge_LLMJudge.csv
docker compose run --rm sim --judge bayes      # → judge_BayesJudge.csv
docker compose run --rm sim --quality-eval --repeat 5   # → quality_eval.csv

# ② 判定する
docker compose run --rm sim --release-gate
# exit 0: 3 シグナルすべて合格 → RELEASE
# exit 2: いずれか不合格     → BLOCK

CI では exit 0 のみマージを許可し、exit 2 でブロックします。

まとめ

  • 品質ゲートの通過だけではリリース判断に足りない。ハルシネーション・法的配慮・品質改善の 3 シグナルが必要
  • release-gate は事前生成 CSV を読むだけで LLM を呼ばず、高速・冪等に判定する
  • ①② ハルシネーション・法的配慮は「NG 0 件」の絶対条件、③ 品質スコアは信頼区間による統計的改善の確認
  • --repeat N（N >= 2）なしでは ③ が機能しないため、quality-eval の実行時に必ず指定する
  • 判定前に CSV を最新化するのが鉄則。古いデータが混入すると判定が汚染される

関連記事