確率的システムの品質保証
LLM は確率的な存在である
AI エージェントを本番に載せたとき、最初にぶつかる壁は品質保証だ。
LLM は確率的な存在である。同じ質問をしても、毎回同じ答えが返る保証はない。従来のソフトウェアテストのように「期待値と一致するか」で判定できない。この不確実性にどう向き合うかで、設計は大きく2つに分かれる。
2つのアプローチ
eval の精度を極める
1つ目は、LLM の出力を事後的に評価する仕組み（eval）の精度を上げるアプローチだ。構造化された判定基準を設計し、LLM に判定させる。決定的な判定と意味的な判定を組み合わせ、検知率を上げ、過検知率を下げる。
技術的に洗練されたアプローチであり、ユースケースによっては合理的な選択だ。
しかし、この方向には構造的な限界がある。データ量と次元数が上がれば上がるほど、eval の評価基準を手書きで管理し続けることができなくなる。eval の精度を上げること自体が、スケールしない。
アーキテクチャで品質を担保する
2つ目は、eval に全賭けせず、上流の設計で品質の下限を保証するアプローチだ。
3つの原則
このアプローチを貫く原則は3つある。
1. LLM にはテキストを渡す。データは渡さない。
LLM に生データを渡して「集計して」と言えば、答えは返ってくる。しかしその答えは毎回違う。数値の見落とし、誤った合算、文脈の取り違え。
LLM はテキストの理解と要約には極めて優秀だが、数値の集計や横断比較は安定しない。だからLLM にデータの分析をさせない。ETL パイプラインが事前にデータを分析し、1つの事実を1つの構造化レポートに変換する。エージェントはそのレポートを「読んで」回答するだけだ。
同じレポートを読めば、同じ事実が出る。回答の揺らぎは「どのレポートを取得したか」に帰着する。品質の制御ポイントが、LLM の出力ではなくレポート選択に移る。
2. 曖昧さは構造で吸収する。
データを粒子化しても、大量のレポートの中から正しいものにたどり着けなければ意味がない。そしてユーザーの入力は常に曖昧だ。
この曖昧さを LLM のプロンプトで吸収するか、構造で吸収するか。ここに設計の分岐がある。
対象に紐づくあらゆる属性を「タグ」として抽出し、それぞれを独立したドキュメントとして検索エンジンに格納する。tag as document だ。タグは DB のラベルではなく、検索可能なドキュメント。曖昧な入力を正確な検索条件に変換する責務を、LLM ではなく検索エンジンが担う。LLM にやらせれば毎回ブレる処理が、検索エンジンなら確定的に動く。
3. 品質は「正しいソースを使ったか」で保証する。
正しいレポートを読めば正しい事実が出る状態と、曖昧な入力から正しいレポートに到達できる状態。この2つが揃って初めて、3番目の原則が成立する。
LLM に「回答は正しいか？」と聞く必要がない。「正しいソースを使ったか？」を静的に検証するだけで、品質の下限を保証できる。
eval がシンプルで済むのは手を抜いているからではない。上流の設計が品質を担保しているからだ。
確率を敵にするか、味方にするか
eval の精度を極めるアプローチは、確率を排除しようとする。1回の判定を確定的に正しくしたい、という思想だ。
アーキテクチャで品質を担保するアプローチは逆で、確率を受け入れる。1回の判定が完璧でなくても構わない。代わりに、複数回実行して統計で品質を見る。
同じ質問を複数のプロトコルで、複数回投げる。得られた複数の回答を比較し、「事実・数値・結論が一致しているか」を一貫性スコアとして算出する。
| スコア | 意味 |
|---|---|
| 1.0 | 全回答が同じ内容 → 信頼できる |
| 0.5 | 主要な事実は一致するが一部に差異 → 要調査 |
| 0.2 以下 | 回答がバラバラ → 設計上の問題がある |
重要なのは、一貫性が低いとき、それは eval の問題ではなく、上流の問題を示唆しているということだ。
一貫性スコアが低下するケースを調べると、エージェントが複数のレポートを読んで自力集約しているのが原因であることが多い。集約の仕方が毎回ブレる。解決策は eval の改善ではなく、集約済みのレポートを用意すること。
eval を改善しても、この問題は解決しない。レポートの設計が品質の上限を決める。 これがアーキテクチャで品質を担保するということだ。
多層品質保証
eval 単体に全賭けしない。検証を4つの層に分解し、各層が1つの問いだけに答える。
第1層「動いたか」 — 回答が返ったか。タイムアウトしなかったか。LLM は使わない。二値判定。
第2層「伝わったか」 — 回答がレポートの事実をきちんと伝えているか。ここだけ LLM を使う。ただし評価基準はシンプルで十分だ。上流が粒子化されているから、回答の揺らぎが小さい。eval に求められる識別力も低くて済む。
第3層「安定しているか」 — 同じ質問に対する複数回答を比較し、事実・数値・結論の一致度をスコアリングする。1回の判定精度を極めるより、複数回回して統計で見る方が信頼できる。
第4層「正しいソースを使ったか」 — LLM は使わない。「この質問なら、この種類のレポートを使うべき」という制約を正規表現でマッチングするだけだ。
第4層が、エコシステム全体の安定性を決定的に高めている。正しいレポートを使っていれば、回答に含まれる事実はレポートに書いてある通りだ。eval は「正しい事実を伝えられているか」という表現面だけ担えばいい。
エコシステムとしての循環
3つの原則と4層の検証は個別に存在するのではなく、循環している。
E2E テストの結果が悪いとき、4つの層の検証結果を突き合わせれば、「何を直すべきか」がわかる。
| 静的判定 | 内容評価 | 一貫性 | レポート検証 | 示唆 |
|---|---|---|---|---|
| NG | - | - | - | 基本動作に問題 |
| OK | NG | - | OK | レポート内容に問題 |
| OK | OK | 低 | OK | レポート粒度に問題 |
| OK | GRAY | - | NG | レポート選択に問題 |
eval 単体の精度を上げても、この診断能力は得られない。問題を検知する仕組みと、問題の所在を特定する仕組みは別物だ。 前者だけでは品質は上がらない。
何層にも仕掛けがあるが、それぞれはシンプルだ。LLM に読ませるレポートが正確だから、eval の判定もシンプルで済む。曖昧な入力を構造で吸収しているから、正しいレポートにたどり着ける。正しいソースを使ったかを静的に検証しているから、LLM に品質を聞かなくていい。どれか1つが欠けても、エコシステムは成立しない。
まとめ
確率的な存在を品質保証するには、確率と戦うのではなく、確率を前提にしたエコシステムを作ること。
eval は品質保証の一部であって、全体ではない。スケールするのは eval の精度ではなく、アーキテクチャの構造だ。
設計の自由度があるなら、この3つの原則から始めてほしい。
- LLM にはテキストを渡す。データは渡さない。
- 曖昧さは構造で吸収する。
- 品質は「正しいソースを使ったか」で保証する。
そしてこの原則の上に、確率を受け入れた検証を重ねる。1回の完璧を目指すより、N回の安定を目指す。eval は最後に、まだ足りない部分だけ補えばいい。