技術要約：LEDGER – ビジネスAIシステムのための決定論的チェックと監査可能な評価

1. 問題提起

公開ベンチマーク（例：Text-to-SQL）は、一般的なタスクに基づいてモデルを評価するものであり、特定の企業の運用データ、ルール、およびオーケストレーション・ロジックに対する性能を予測するものではない。デプロイされたAIアシスタントは、モデル、プロンプト、ツール、データアクセス・ポリシー、およびオーケストレーションからなる複合システムであり、これらのいずれかのコンポーネントに変更を加えることで、正確性が変化する可能性がある。さらに、公開テスト項目はトレーニングデータにリークしやすく、記憶によるスコアの膨張を招く。企業は、自社のデータを用いて、変更のたびに自社のAIシステムを再テストするための、実用的かつ反復可能なメカニズム、および特定の証拠に遡って監査・追跡可能なスコアを得る手段を欠いている。

2. 手法：LED_GERプラットフォーム

著者らは、企業のデータ、質問、およびルールを反復可能なテストへと変換するために設計された評価プラットフォームであるLEDGER（Logged Evidence for Deterministic, Governed Evaluation and Review）を提示している。

コアアーキテクチャ

• シナリオ定義： 各テストケース（シナリオ）は、質問またはインターフェースのアクション、期待される結果、およびエビデンス（証拠）ソースを記録する。エビデンスソースには以下が含まれる：
  • 凍結されたSQLクエリ： 企業のデータウェアハウスの凍結されたコピーに対して実行される。
  • フィクスチャ： テスト文書から抽出された、手入力された事実。
  • ポリシー・ルール： 拒絶（例：PII/個人情報）や明確化の要求に関する決定論的なチェック。
  • インターフェース契約： ダッシュボードの状態遷移の検証。
• 決定論的チェック（オラクル）： 結果がエビデンスから計算可能である場合（例：特定の数値や拒絶）、決定論的チェックが回答をスコアリングする。これにより、判定が毎回同一であることを保証する。
• ログ記録されたLLMレビュー： 決定論的チェックでは解析できない文章形式の回答については、別のLLOMジャッジが回答を評価する。極めて重要な点として、このジャッジは決定論的なエビデンス・チェックによって制約を受ける。判定は、回答がエビデンス・チェック（例：文章内で正しい値を述べていること）とジャッジの承認の両方をパスした場合にのみ有効となる。
• プロベナンス（由来）と凍結： すべての実行において、モデルのアイデンティティ、プロンプトのハッシュ、シナリオのコンテンツ・ハッシュ、ツール・スキーマ、および生の出力が記録される。これにより、すべてのスコアを特定の証拠まで遡ることができ、同じシナリオを異なるシステムに対して再実行することが可能になる。

実験デザイン

本プラットフォームは、エンジニアリングおよびオペレーションのウェアハウスをクエリするInterval社のビジネスインテリジェンス・アシスタントに適用された。

• テスト対象システム（SUT）： カスタムタスク・ハーネス（プロンプト、ルールパック、スキル、サブエージェント、および4つの管理されたデータツール）内で、プライベートにホストされたオープンウェイトモデルであるDeepSeek V4 Flash (DS4)を実行するDS4+harness。
• ベースライン： 7つのモデルがテストされた：5つのプロプライエタリな最先端モデル（GPT-5.6 Sol/Terra, Claude Opus/Sonnet/Fable）、オープンウェイトのGLM-5.3、および「素の」状態で動作するDS4。
• プロンプト条件：
  • スキーマのみ： ウェアハウスのテーブルとカラムをリストアップする。
  • スキーマ＋レジストリ： 企業のメトリック・レジストリ（定義、契約、およびSQLロジック）を追加する。
• データセット：
  • 開発セット（814シナリオ）： ハーネスを反復的に構築および修復するために使用。
  • テストセット（97シナリオ）： データリークを防ぐため、開発セットには存在しない新しい値を使用して、ハーネスの凍結後に生成。

3. 主な貢献

1. LEDGERプラットフォーム： シナリオ、エビデンス、システム構成、およびスコアリング手法を分離するシステム。決定論的なスコアリングが可能な場合は決定論的に行い、必要な場合には制約付きのLLMレビューを行うことで、すべてのスコアがエビデンスに紐付くことを保証する。
2. システム対モデルの貢献に関するケーススタディ： 本研究は、「ハーネス」（オーケストレーションとルール）の価値をベースモデルから分離して検証している。これは、企業の特定のハーネスおよびメトリック・レジストリによって拡張されることで、プライベートにホストされたオープンウェイトモデル（DS4）が最先端レベルの精度を達成できることを示している。
3. コスト・精度トレードオフ分析： 「正解あたりのコスト」を主要な指標として導入し、精度を正規化した際、プロプライエタリなAPIとセルフホスト型のオープンウェイトモデルとの間に顕著なコスト格差があることを明らかにしている。

4. 結果

精度

保持されたテストセット（97シナリオ）において：

• DS4+harnessは96/97の正解を達成した。
• 素のDS4（レジストリあり）は94/97を達成した。
• 最先端モデル（プロプライエタリ + GLM-5.3）は94〜97/97を達成した。
• 素のDS4（スキーマのみ）は89/97であり、最先端モデルに遅れをとった。
• ハーネスの影響： ハーネスは、素のDS4の正解数を89から96へと引き上げた。メトリック・レジストリ単体でも、レジストリがない場合の素のDS4で失われた7ポイントのうち5ポイントを回復させた。最先端モデルは、レジストリの有無に関わらず同様のパフォーマンスを示した。

コスト効率

「スキーマ・プラス・レジストリ」プロンプトを使用した場合：

• セルフホスト型DS4（素の状態）の正解あたりの推定コストは$0.0010–$0.0018であった。
• プロプライエタリな最先端モデルの正解あたりのコストは**$0.0111 to $0.0766**であった。
• 倍率： 最先端モデルは、正解あたりのコストにおいて、セルフホスト型DS4よりも推定で6倍から77倍高価であった。DeepSeekのオフピークAPIレートを使用した場合でも、コストはセルフホスト型より1.6倍から3.0倍高かった。

開発セットの観察

開発セット（814シナリオ）において、DS4+harnessは808を通過した。ベースラインは627から650の間を通過した。しかし、著者らは、これらの数値がベースラインの性能を過小評価していると指摘している。理由は、多くのベースラインの回答が保存された記録（ログの欠落など）から「判定不能」であったこと、およびハーネスがこの特定のデータに対して反復的にチューニングされたためである。

5. 意義と主張

本論文は、LEDGERが、企業が精度を損なうことなくオープンウェイトのセルフホスト型モデルを採用するための、防御可能なフレームワークを提供すると主張している。

• 測定可能なトレードオフ： 精度とコストのトレードオフを明示的にしている。複数のモデルが一度企業の定義が明示された段階で同等の精度に達する場合、モデルの選択は「最先端」のランキングに基づく盲目的な依存ではなく、コストと制御に基づくエンジニアリング上の決定となる。
• 反復的な改善： すべての失敗が特定のシナリオ、期待値、およびルールを指し示すため、システムはターゲットを絞った修復（多くの場合、コーディングエージェントによって駆動される）を可能にし、同時に人間によるレビューが「正解」の定義を検証する。
• 監査可能性： プラットフォームは、評価結果がブラックボックスではないことを保証する。すべてのスコアはエビデンスに遡ることができ、レビュープロセスはバージョン管理されたジャッジと共に記録される。

著者らは、このようなテストがなければ、「安全な選択」は高価なプロプライエタリモデルに留まることであると結論付けている。LEDGERがあれば、企業は自社のワークロードに対して、極めて低いコストで最先端レベルの精度を達成でき、モデルの選択を測定可能で防御可能なエンジニアリング上の決定にすることができる。

6. 限界

論文では以下の限界を明示的に認めている：

• 天井効果： システムはテストセットにおいて上限に近い状態にある。そのため、単一の実行ではシステムを決定的にランク付けしたり、同等性を確立したりすることはできない。
• テンプレート依存性： シナリオ間でクエリ・ロジックが共有されており、ペアテストにおいてエビデンスが過大評価される可能性がある。
• レビューの変動性： LLMレビューは制約されているものの、依然として非決定論的である。論文では、再実行時のジャッジの変動について報告している。
• 監査範囲： 人間による監査は単一の著者によって行われ、完全にブラインド（盲検）な状態ではなかったため、独立したエラー推定には限界がある。
• スコープ： プラットフォームは一つの企業のタスクとツール呼び出しモデルに対してデモンストレーションされたものであり、機密データに依存するため、外部での再現性は限定的である。