規制対応が必要なRAGシステムの推論コストを6倍削減するカスケード設計

全LLMパイプラインの隠れたコスト

記事が指摘するのは、監査や規制の対象となる分類システムで、すべてのケースをLLMにルーティングする構成には3つの問題があるという点だ。まず監査可能性で、「モデルが取得したコンテキストに基づいて判断した」という説明では、人間が意思決定経路を再現できない。次にコストで、1日数万件を処理し、すべてのケースに検索ドキュメントを入れてLLMを呼び出すと、推論費用とレイテンシが処理量に比例する。3つ目に、決定論的に答えられるはずのケースでモデルが一貫しない、モデルドリフトの問題がある。LLMは対応が難しい判断は得意だが、簡単なケースでは検出しにくい不安定さを持つという。

この3つは、デモでは表面化しない。監査やコンプライアンスの担当者から、6か月前の判断理由を問われたときに初めて、構成の欠陥が露呈すると記事は述べている。特に、LLMの呼び出しは再実行すれば出力が変わりうるため、記録だけでは追跡できないという難しさがある。

カスケード構成の3段階

解決策は、LLMを最前線ではなくエスカレーションの手段として使うことだ。具体的には3段階のパイプラインを組む。第1段階は決定論的で、完全一致や構造化フィールドの比較、明確なルールがあるものをモデル呼び出しなしで処理する。データ品質にもよるが、多くの場合、全体の過半数をここで捌けるとされる。

第2段階は検索で、第1段階で解決できなかったケースについて、類似事例や過去の審査判断、文書などを取得する。この段階では、検索の品質が生成よりも重要になる。第3段階で初めてLLMを呼び出す。LLMには第1・第2段階で解決できなかった残差だけが渡される。多くの設計者は検索結果を何でもLLMに渡してしまうが、ここがコストと品質の最大のレバーになる。

記事が関わったシステムでは、本当に曖昧な10〜15%に絞ったところ、全LLM構成と比べて推論コストが約6倍削減された。さらに、決定論的に処理できる多数派の一貫性はほぼ完璧に向上したという。ただし、この数値はデータ品質や業務内容に依存する点に注意が必要だ。

LLM段階のプロンプト設計

LLMにケースが到達したとき、多くのチームは「このケースを承認すべきか、フラグを立てるべきか」という中立的なプロンプトを使う。しかし、高リスクな分類では、2種類の誤りのコストは対称ではない。見逃してしまうと下流で実際の被害につながる可能性がある一方、問題のないものを誤ってフラグすると、レビュアーの時間と遅延を生む。これらのコストが異なるにもかかわらず、中立的なプロンプトはモデルに同じ重みで扱うよう求めることになる。

記事はこのような非対称リスクをプロンプト設計に反映すべきだと指摘する。ただし、具体的なプロンプトの文言は公開されておらず、どのようにリスクの重みを組み込むかはチームごとの設計判断になるとみられる。この点は、監査要件に応じてカスタマイズが必要になると考えられる。

現時点で不明な点と注意点

この記事は特定の企業システムでの経験に基づくもので、汎用のフレームワークや製品を紹介しているわけではない。数値もそのシステムのデータ品質と要件に依存する。また、第2段階の検索が誤った文脈を取得すると、どんなLLMでも自信満々に筋の通った誤答を出すため、検索層の精度が全体の品質を左右する。カスケード構成を採用する場合、最初から完全に自動化するのではなく、決定論的ルールを徐々に増やしながら検証する進め方が考えられる。

さらに、監査対応として必要なログやトレーサビリティの具体的な実装方法は記事では明らかにされていない。導入を検討する組織は、自社の監査要件に合わせて記録項目や保存期間を設計する必要がある。どのような情報を残せば監査に耐えられるかの共通指針は、まだ確立されていないのが現状だ。