要旨
企業運営における AI エージェントの急増には、品質測定に対する厳格で標準化されたアプローチが必要です。関数が正しい値を返すか返さない従来のソフトウェアとは異なり、AI エージェントは複数ステップのワークフローにわたって状況に応じた決定を下し、さまざまな適切性でガバナンス ゲートを呼び出し、さまざまな完全性の証拠バンドルを生成し、これらすべてをレイテンシーの制約の下で実行します。標準化された評価インフラストラクチャが存在しないということは、エージェントの品質が通常、逸話的な観察、スポットチェック、またはインシデント後の分析を通じて評価されることを意味します。いずれもスケールがなく、再現性がなく、体系的な改善に必要な継続的なフィードバック ループを提供するものはありません。
このペーパーでは、エージェント品質測定の第一原理に基づいて設計されたテスト インフラストラクチャである MARIA OS 評価ハーネスを紹介します。私たちは、エージェントの品質領域を集合的にカバーする 4 つのテスト カテゴリを定義します。正確性 (エージェントは正しい決定を下しているか?)、安全性 (エージェントは有害な行動を回避しているか?)、パフォーマンス (エージェントは遅延とスループットの要件を満たしているか?)、ガバナンス コンプライアンス (エージェントは組織の意思決定アーキテクチャを尊重しているか?) です。カテゴリごとに、具体的な指標、しきい値基準、評価プロトコルを指定します。
ハーネス アーキテクチャは 4 つのコンポーネントで構成されています。決定論的なシードを使用してシナリオの実行を調整する テスト ランナー、ドメイン テンプレートからパラメータ化されたテスト ケースを生成する シナリオ ジェネレーター、検証された参照決定に対してエージェントの出力を評価する Oracle コンパレーター、および評価実行全体で統計的に重大な品質低下を特定する 回帰検出器です。すべてのコンポーネントは MARIA 座標系でスコープ設定されており、個々のエージェントからユニバース全体に至るまで、組織階層のあらゆるレベルを対象としたテストが可能です。
1. はじめに: エージェントの品質に標準化された測定が必要な理由
ソフトウェア エンジニアリングは、単体テスト、統合テスト、プロパティ ベースのテスト、突然変異テスト、パフォーマンス ベンチマークといったテスト手法の開発に数十年を費やしました。エンジニアは、テストされていないコードは信頼性の低いコードであることを、つらい経験を通じて学んだからです。 AI エージェント エコシステムは初期段階にあります。意思決定が重要なワークフローにエージェントを導入していますが、同等のテスト インフラストラクチャがありません。
ギャップは単にツールの問題ではありません。それは概念的なものです。従来のテストでは、決定論的契約を検証します。入力 X が与えられると、関数は Y を返す必要があります。エージェントの評価は、確率的ポリシーを検証する必要があります。コンテキスト C が与えられると、エージェントはガバナンス制約 G を尊重しながら、許容可能な分布 D 内で意思決定を下す必要があり、レイテンシー制限 L 内で品質 Q の証拠を生成します。この多次元品質空間には、根本的に異なる評価フレームワークが必要です。
エージェント テストと従来のソフトウェア テストを区別する 3 つの特性:
| Dimension | Traditional Software Testing | Agent Quality Evaluation |
| --- | --- | --- |
| Correctness | Deterministic: exact output match | Distributional: acceptable decision range |
| Safety | Boundary validation, null checks | Behavioral constraint verification over trajectories |
| Performance | Throughput, latency (single operation) | Decision quality under resource constraints |
| Compliance | API contract adherence | Governance gate invocation, evidence production |MARIA OS 評価ハーネスは、次元の透明性を維持しながら単一の複合品質スコアを生成する統合アーキテクチャを通じて 4 つの次元すべてに対応します。
2. テストカテゴリー
2.1 正確性
正確性評価では、エージェントが検証された参照結果と一致する意思決定を行うかどうかを測定します。正確性が 2 値である単体テストとは異なり、エージェントの正確性はスペクトル上に存在します。人間によるレビューを行わずにリスクの低い経費報告書を承認するエージェントは、ある組織の状況では正しくても、すべての経費にマネージャーの承認が必要な別の状況では正しくない可能性があります。
意思決定オラクル (テスト スイート内の各シナリオの正しいアクションを指定する検証済みの参照ポリシー) に基づいて正確さを定義します。オラクルはドメインの専門家によって構築され、(コンテキスト、アクション) ペアを正当性ラベルにマッピングするデシジョン テーブルとしてエンコードされます。
interface DecisionOracle {
scenarioId: string;
context: ScenarioContext;
expectedAction: AgentAction;
acceptableVariants: AgentAction[];
correctnessWeight: number; // importance of this scenario [0, 1]
}
function evaluateCorrectness(
agent: AgentUnderTest,
oracle: DecisionOracle[],
seed: number
): CorrectnessReport {
const prng = createPRNG(seed);
const results = oracle.map((scenario) => {
const agentAction = agent.decide(scenario.context, prng);
const isExactMatch = deepEqual(agentAction, scenario.expectedAction);
const isAcceptable = scenario.acceptableVariants.some(
(v) => deepEqual(agentAction, v)
);
return {
scenarioId: scenario.scenarioId,
correct: isExactMatch || isAcceptable,
exact: isExactMatch,
weight: scenario.correctnessWeight,
};
});
const weightedAccuracy =
results.reduce((sum, r) => sum + (r.correct ? r.weight : 0), 0) /
results.reduce((sum, r) => sum + r.weight, 0);
return { results, weightedAccuracy };
}2.2 安全性
安全性評価では、敵対的または曖昧な入力によって促された場合でも、エージェントが有害として分類される行動を決してとらないことを検証します。安全性テスト シナリオは、境界条件、つまり正しいアクションが直接実行ではなく拒否、エスカレーション、またはゲート呼び出しであるエッジ ケースを調査するように設計されています。
当社では、安全違反を 3 つの重大度レベルに分類しています。 S1 (重大) - 取り返しのつかない損害を引き起こす行為、または法的制約に違反する行為。 S2 (深刻) — ガバナンスゲートを迂回する行為、または不完全な証拠を提出する行為。 S3 (マイナー) — 最適ではないが、安全性の不変条件には違反しないアクション。ハーネスは S1 違反に対してゼロトレランス ポリシーを適用します。つまり、S1 違反を 1 つでも発生させるエージェントは、他のすべてのスコアに関係なく安全性評価に不合格となります。
2.3 パフォーマンス
パフォーマンス評価では、レイテンシ バジェット、同時リクエストの負荷、インフラストラクチャの劣化状況など、リソースの制約の下でエージェントの意思決定の品質を測定します。重要な洞察は、エージェントのパフォーマンス テストは単に速度に関するものではないということです。それは グレースフル デグラデーション に関するものです。負荷がかかっているときに、迅速ではあっても間違った回答を返すエージェントは、レイテンシ バジェット内で品質のしきい値を満たせない場合に人間に正しくエスカレーションするエージェントよりも劣悪です。
interface PerformanceScenario {
concurrentRequests: number;
latencyBudgetMs: number;
infrastructureDegradation: "none" | "partial" | "severe";
expectedBehavior: "normal" | "graceful-degradation" | "escalation";
}
const PERFORMANCE_SCENARIOS: PerformanceScenario[] = [
{ concurrentRequests: 1, latencyBudgetMs: 500, infrastructureDegradation: "none", expectedBehavior: "normal" },
{ concurrentRequests: 50, latencyBudgetMs: 2000, infrastructureDegradation: "none", expectedBehavior: "normal" },
{ concurrentRequests: 200, latencyBudgetMs: 5000, infrastructureDegradation: "partial", expectedBehavior: "graceful-degradation" },
{ concurrentRequests: 500, latencyBudgetMs: 10000, infrastructureDegradation: "severe", expectedBehavior: "escalation" },
];2.4 ガバナンスのコンプライアンス
ガバナンス コンプライアンス評価では、エージェントが組織の意思決定アーキテクチャに正しく参加していることを検証します。これには、適切な意思決定ポイントで必要な責任ゲートを呼び出すこと、スキーマ仕様を満たす証拠バンドルを作成すること、自律性のしきい値を超える決定に対する承認ワークフローを尊重すること、監査可能性を確保するためにすべてのアクションを MARIA 座標で記録することが含まれます。
ガバナンス コンプライアンスは、MARIA OS 評価ハーネスの最も特徴的なテスト カテゴリであり、従来のソフトウェア テストに相当するものはありません。セキュリティ テストではソフトウェアが悪用できないことを検証しますが、ガバナンス コンプライアンス テストではエージェントが組織の責任構造に積極的に参加していることを検証します。
3. 評価指標
3.1 判定精度 (DA)
意思決定精度は、評価シナリオ セット全体での正しい意思決定の重み付けされた割合を測定します。
DA = (\sum_{i=1}^{N} w_i \cdot \mathbb{1}[a_i \in A_i^{\text{correct}}]) / (\sum_{i=1}^{N} w_i)ここで、w_i はシナリオ i の重要度の重み、a_i はエージェントのアクション、A_i^{correct} はオラクルによって定義された許容可能なアクションのセットです。エージェントのアクションが許容可能なセット内にある場合、インジケーター関数は 1 を返します。
3.2 ゲートコンプライアンス率 (GCR)
ゲート準拠率は、エージェントが必要な責任ゲートを正しく呼び出す、ガバナンスに敏感な意思決定ポイントの割合を測定します。
GCR = |\{ d \in D_{\text{gated}} : \text{gate}(d) = \text{gate}_{\text{required}}(d) \}| / |D_{\text{gated}}|ここで、D_gated はゲートの呼び出しを必要とするすべての意思決定ポイントのセットであり、分子はエージェントが正しいゲート タイプ (人間参加型、承認ワークフロー、証拠収集など) を呼び出した意思決定の数をカウントします。
3.3 証拠品質スコア (EQS)
証拠品質スコアは、エージェントによって作成された証拠バンドルの完全性、トレーサビリティ、および正確さを評価します。各証拠バンドルは、次の 3 つのサブディメンションにわたってスキーマ仕様に対してスコア付けされます。
EQS = \alpha \cdot \text{completeness}(E) + \beta \cdot \text{traceability}(E) + \gamma \cdot \text{correctness}(E)ここで、アルファ + ベータ + ガンマ = 1。完全性は、すべての必須フィールドが存在するかどうかを測定します。トレーサビリティは、証拠チェーンが MARIA 座標を通じてソース データにリンクしているかどうかを測定します。正確性は、証拠の内容が基礎となる意思決定のコンテキストを正確に表しているかどうかを測定します。
3.4 負荷時のレイテンシ (LUL)
負荷時の待ち時間は、各パフォーマンス シナリオの待ち時間バジェットに対して正規化されたエージェントの p95 応答時間を測定します。
LUL = 1 - \text{min}(1, p_{95}(\text{latency}) / L_{\text{budget}})LUL スコア 1.0 は、エージェントの p95 遅延がゼロ (理論上の最大値) であることを意味します。スコア 0.0 は、p95 レイテンシーが予算とまったく同じか、予算を超えていることを意味します。負の値はゼロにクランプされます。
4. 総合エージェントスコア
4 つの指標は加重幾何平均を使用して単一の複合エージェント スコア (CAS) に結合されます。これにより、単一の側面での壊滅的な障害が他の側面の優秀さによって覆い隠されることがなくなります。
CAS = DA^{w_1} \cdot GCR^{w_2} \cdot EQS^{w_3} \cdot LUL^{w_4}ここで、w_1 + w_2 + w_3 + w_4 = 1。MARIA OS のデフォルトの重みは、w_1 = 0.35 (正確性)、w_2 = 0.30 (ガバナンス)、w_3 = 0.20 (証拠)、w_4 = 0.15 (パフォーマンス) です。幾何平均には、いずれかの要素がゼロの場合、複合スコアもゼロになるという重要な特性があります。つまり、ガバナンス コンプライアンスに完全に失敗したエージェントは、決定の精度に関係なく、CAS が 0 になります。
The CAS weights are not engineering parameters — they are organizational policy. An enterprise that prioritizes governance compliance over raw accuracy should increase w_2 relative to w_1. MARIA OS requires that weight changes go through the decision pipeline with evidence justification, ensuring that the evaluation criteria themselves are governed.定理 (単調な応答性)。 複合エージェント スコアは、個々のメトリックの真の改善に関して単調に減少せず、他のすべてのメトリックは一定に保たれます。
証明 CAS = DA^{w_1} GCR^{w_2} EQS^{w_3} * LUL^{w_4} とします。他のすべてのメトリックが一定のまま、DA_0 から DA_1 (DA_1 > DA_0 >= 0) への DA の改善を考えてみましょう。 DA_1 / DA_0 > 1 かつ w_1 > 0 であるため、CAS_1 / CAS_0 = (DA_1 / DA_0)^{w_1} > 1 となります。したがって、CAS_1 > CAS_0 となります。引数はすべてのメトリックに対して対称です。 QED。
5. ハーネスアーキテクチャ
評価ハーネスは、パイプライン アーキテクチャに配置された 4 つのコンポーネントで構成されます。
5.1 テストランナー
テスト ランナーは、再現性を確保するために決定論的なシード処理を使用してシナリオの実行を調整します。各評価実行は、実行トレース全体を一意に決定する (suite_id、seed、timestamp) トリプルによって識別されます。ランナーは、シナリオ表示の決定的な順序を維持しながら、複数のエージェント インスタンスにわたる並列実行をサポートします。
interface EvaluationRun {
suiteId: string;
seed: number;
timestamp: Date;
coordinate: MARIACoordinate; // scope of evaluation
agent: AgentUnderTest;
scenarios: EvaluationScenario[];
config: RunConfig;
}
interface RunConfig {
parallelism: number;
timeoutMs: number;
failFast: boolean; // stop on first S1 safety violation
recordTraces: boolean;
}
async function executeRun(run: EvaluationRun): Promise<RunResult> {
const prng = createPRNG(run.seed);
const scenarios = shuffleWithSeed(run.scenarios, prng);
const results: ScenarioResult[] = [];
for (const batch of chunk(scenarios, run.config.parallelism)) {
const batchResults = await Promise.all(
batch.map((s) => executeScenario(run.agent, s, prng))
);
results.push(...batchResults);
if (run.config.failFast && batchResults.some((r) => r.safetyLevel === "S1")) {
return { status: "failed-safety", results, abortedAt: results.length };
}
}
return { status: "completed", results };
}5.2 シナリオジェネレーター
シナリオ ジェネレーターは、ドメイン テンプレートからパラメーター化されたテスト ケースを生成します。各テンプレートは、意思決定コンテキスト スキーマ、可変パラメータのセット、および各パラメータの組み合わせに対する Oracle 検証済みの正しいアクションを定義します。テンプレートは MARIA 座標ごとに編成されているため、特定のドメイン向けにターゲットを絞ったテストを生成できます。
このジェネレーターは、網羅的 (すべてのパラメーターの組み合わせ)、ランダム (指定されたシードによるモンテカルロ サンプリング)、敵対的 (既知のエッジ ケースおよび過去の故障モードに偏ったパラメーター選択) の 3 つのモードをサポートします。
5.3 Oracle コンパレータ
Oracle Comparator は、検証済みの参照決定に対してエージェントの出力を評価します。単純な同等性チェックとは異なり、コンパレーターは 部分的な正しさ をサポートします。つまり、エージェントの決定が部分的に正しい可能性があることを認識します (例: アクションは正しいが証拠が不完全、またはエスカレーションは正しいがゲート レベルが間違っているなど)。
コンパレータは、シナリオごとに多次元の正確性ベクトルを生成し、それがセクション 3 で説明されているメトリック計算に入力されます。
5.4 回帰検出器
Regression Detector は、評価実行全体で統計的に重大な品質低下を特定します。 CAS スコアのローリングベースラインを維持し、仮説テストを適用して回帰を検出します。
H_0: \mu_{\text{current}} \geq \mu_{\text{baseline}} \quad \text{vs} \quad H_1: \mu_{\text{current}} < \mu_{\text{baseline}}有意水準 alpha = 0.01 の片側 t 検定が適用されます。 H_0 が拒否された場合、回帰検出機能は MARIA OS 決定パイプラインを介したデプロイメントをブロックするアラートを生成します。この検出器はメトリクスごとの回帰も追跡するため、単一のディメンションが原因で複合スコアが低下した場合に的を絞った調査が可能になります。
6. MARIA 座標ベースのテスト範囲設定
評価ハーネスの最も強力な機能の 1 つは、MARIA 座標系との統合です。テストの範囲は組織階層の任意のレベルに設定できます。
// Evaluate a single agent
const agentScope: TestScope = {
coordinate: "G1.U2.P3.Z1.A5",
level: "agent",
inheritParentScenarios: true,
};
// Evaluate all agents in a zone
const zoneScope: TestScope = {
coordinate: "G1.U2.P3.Z1.*",
level: "zone",
includeInterAgentScenarios: true,
};
// Evaluate an entire universe
const universeScope: TestScope = {
coordinate: "G1.U2.*.*.*",
level: "universe",
includeCrossZoneScenarios: true,
includeCrossPlanetScenarios: true,
};階層的なスコープ設定とは、テスト スイートが自然に構成されることを意味します。ゾーン レベルの評価には、そのゾーン内のエージェントのすべてのエージェント レベルのシナリオに加えて、エージェント間の調整シナリオが含まれます。ユニバースレベルの評価には、すべてのゾーンレベルの評価に加えて、ゾーン間の相互作用シナリオが含まれます。この構成可能性により、個別のテスト スイートのメンテナンスを必要とせずに、組織階層のあらゆるレベルで品質が検証されることが保証されます。
7. エージェントスコアリングの正式なフレームワーク
評価フレームワークをタプル (S、A、O、M、C) として形式化します。ここで、
- S = シナリオ空間、考えられるすべての評価コンテキストのセット
- A = アクション スペース、すべての可能なエージェント応答のセット
- O = オラクル関数、O: S -> P(A)、許容可能なアクションのセットへのシナリオのマッピング
- M = 計量関数、M = {DA、GCR、EQS、LUL}
- C = 合成関数、C: R^4 -> R、メトリック スコアを合成スコアにマッピング
エージェント pi は確率的ポリシー pi: S -> Delta(A) シナリオをアクション全体の確率分布にマッピングします。メトリック m でのエージェント pi の期待品質は次のとおりです。
Q_m(\pi) = \mathbb{E}_{s \sim \mathcal{S}, a \sim \pi(s)}[m(a, O(s))]複合品質は次のようになります。
Q(\pi) = C(Q_{DA}(\pi), Q_{GCR}(\pi), Q_{EQS}(\pi), Q_{LUL}(\pi))定理 (分離性) 複合品質 Q(pi) は、シナリオのコンテキストを考慮して計量関数が条件付きで独立している場合に限り、独立した計量ごとの評価に分解できます。
この分離可能性の特性は、実際の評価にとって重要です。つまり、すべてのテスト シナリオで 4 つの側面すべてを同時に評価する必要がなく、正確性、安全性、パフォーマンス、ガバナンスのテストを個別に実行して結果を構成できることを意味します。
8. 継続的な評価パイプライン
評価ハーネスは 1 回限りのツールではなく、MARIA OS 導入ワークフローに統合された継続的なパイプラインとして動作します。
interface ContinuousEvaluationPipeline {
// Trigger conditions
triggers: {
onAgentUpdate: boolean; // re-evaluate when agent code changes
onOracleUpdate: boolean; // re-evaluate when oracle is updated
scheduled: CronExpression; // periodic re-evaluation (e.g., daily)
onIncident: boolean; // re-evaluate after production incidents
};
// Pipeline stages
stages: [
"scenario-generation", // generate or refresh test scenarios
"agent-execution", // run agent against scenarios
"oracle-comparison", // compare outputs to oracle
"metric-calculation", // compute DA, GCR, EQS, LUL
"regression-detection", // statistical comparison to baseline
"report-generation", // produce human-readable report
"gate-decision", // pass/fail/escalate decision
];
// Output
result: "deploy" | "block" | "escalate-to-human";
}パイプラインは、エージェント コードの更新、Oracle 仕様の更新、スケジュールされた間隔 (デフォルト: 毎日)、運用インシデント レポートの 4 つのトリガーで自動的に実行されます。実行ごとに、複合スコア、メトリックごとの内訳、回帰分析、および導入の推奨事項を含む評価レポートが生成されます。
ゲート決定段階は特に重要です。この段階では、評価結果が MARIA OS 決定パイプラインを通じてガバナンス アクションに変換されます。すべてのしきい値を通過したエージェントは、自動導入承認を受け取ります。 S1 安全シナリオに失敗したエージェントは自動的にブロックされます。許容範囲内である可能性のあるわずかな GCR 回帰などの中間ケースは、責任ゲート システムを通じて人間のレビュー担当者にエスカレーションされます。
9. 従来のソフトウェアテストとの比較
次の表は、従来のソフトウェア テストと MARIA OS 評価ハーネス アプローチの主な違いをまとめたものです。
| Aspect | Traditional Testing | MARIA OS Evaluation Harness |
| --- | --- | --- |
| Correctness criterion | Exact output match | Oracle-validated acceptable range |
| Test determinism | Fully deterministic | Deterministic via seeded PRNG |
| Safety verification | Negative testing (invalid inputs) | Behavioral trajectory analysis |
| Performance testing | Load testing (throughput/latency) | Quality-under-constraint evaluation |
| Compliance testing | N/A or manual audit | Automated governance gate verification |
| Test scoping | Package/module hierarchy | MARIA coordinate hierarchy |
| Regression detection | Diff-based (pass/fail) | Statistical hypothesis testing |
| Evaluation output | Pass/fail | Composite score with dimensional breakdown |
| Continuous integration | On code change | On code change + oracle change + schedule + incident |
| Governance integration | None | Full decision pipeline integration |最も根本的な違いは哲学的なものです。従来のテストでは、「コードは仕様に記載されているとおりに動作するか?」と尋ねられます。評価ハーネスは、「エージェントは、組織が承認したプロセスを通じて、組織が監査できる証拠を伴って、組織が承認するような決定を下しているか?」と尋ねます。
10. シナリオ設計の原則
効果的な評価には、適切に設計されたシナリオが必要です。私たちはエージェント評価におけるシナリオ設計の 5 つの原則を提案します。
原則 1: ボリュームよりもカバレッジ。 4 つのテスト カテゴリすべてとすべての MARIA 座標レベルをカバーする 500 のシナリオを含むテスト スイートは、エージェント レベルでの正確性のみをテストする 50,000 のシナリオを含むスイートよりも価値があります。シナリオ ジェネレーターは、体積拡張の前に次元範囲を優先する必要があります。
原則 2: 敵対的シナリオは必須です。 すべてのテスト スイートには、既知の障害モード (あいまいなコンテキスト、矛盾する制約、リソースのプレッシャー、連鎖的なエラー状態) を調査する敵対的シナリオが含まれている必要があります。シナリオの少なくとも 20% は敵対的である必要があります。
原則 3: オラクルのメンテナンスはガバナンスです。 オラクルは組織の判断を表します。オラクルで検証された正しいアクションへの変更は組織ポリシーの変更であり、証拠の正当性を伴う意思決定パイプラインを通過する必要があります。
原則 4: シナリオの出自。 すべてのシナリオは、テンプレートから生成されたか、運用インシデントから派生したか、ドメインの専門家によって設計されたかにかかわらず、そのソースまで追跡可能である必要があります。 Provenance により、エージェントが特定のシナリオに失敗した場合の根本原因分析が可能になります。
原則 5: 一時的な有効性。 シナリオには有効期限があります。組織のポリシーは変化し、ドメインの知識は進化し、許容できる意思決定の範囲は変化します。ハーネスはシナリオの有効期間を追跡し、古いシナリオにレビュー用のフラグを立てます。
11. 実装に関する考慮事項
The evaluation harness runs in an isolated environment separate from production. Agent instances under test receive no production traffic and have no access to production data. The harness environment mirrors the production MARIA OS configuration but uses synthetic data generated by the scenario generator. This isolation ensures that evaluation cannot impact production operations and that evaluation results are not contaminated by production state.主な実装の詳細には次のものが含まれます。
決定的シード。 評価パイプラインのランダム性のすべてのソースは、シードされた PRNG (mulberry32、MARIA OS Civilization Engine と一致) によって制御されます。これは、評価実行が完全に再現可能であることを意味します。同じ (suite_id、seed、timestamp) トリプルが与えられた場合、ハーネスは同じ結果を生成します。
順序付けが保証された並列実行。 バッチ内のシナリオはパフォーマンスのために並列実行されますが、バッチはフェイルファスト動作を可能にするために順次実行されます。決定論的シャッフルにより、位置に依存するバイアスを回避しながら、シナリオの順序が実行全体で一貫していることが保証されます。
証拠収集。 ハーネスは、エージェントの内部状態 (利用可能な場合)、意思決定根拠ログ、ゲート呼び出し、証拠バンドルなど、あらゆるシナリオの完全な実行トレースを記録します。これらのトレースは、メトリック計算と評価後のデバッグという 2 つの目的を果たします。
ベースライン管理 回帰検出機能は、CAS スコアのローリング 30 日間のベースラインを維持します。ベースラインはエージェントが改善されると自動的に更新されますが、更新は非対称です。改善によってベースラインは上昇しますが、回帰によってベースラインが下降することはありません。このラチェット機構により、時間の経過とともに品質が向上します。
12. 結論と今後の方向性
MARIA OS 評価ハーネスは、エージェントの品質を不透明で主観的な評価から透明で再現可能なエンジニアリング測定に変換します。このハーネスは、4 つのテスト カテゴリ、4 つの主要指標、正式な複合スコアリング フレームワーク、および MARIA OS ガバナンス インフラストラクチャと統合された継続的評価パイプラインを定義することにより、体系的なエージェント品質管理の基盤を提供します。
この文書の主な貢献は次のとおりです。
1. 正確性、安全性、パフォーマンス、ガバナンスのコンプライアンスをカバーするエージェントの品質評価のための 正式なテスト分類法 2. 4 つの具体的な指標 (DA、GCR、EQS、LUL) と数学的定義および測定プロトコル 3. 実証済みの単調応答性と分離性特性を備えた複合スコアリング フレームワーク 4. 統計的回帰検出とガバナンス統合による継続的評価のためのアーキテクチャ 5. MARIA 座標ベースのテスト スコーピング により、個々のエージェントからユニバース全体までの階層的な品質検証が可能になります
今後の作業には、(個々のエージェントの品質だけでなく) マルチエージェントの調整品質を評価するためのハーネスの拡張、オラクル構築のための転移学習アプローチの開発 (新しい評価スイートの作成に必要なドメイン専門家の労力の削減)、競争力のある多国籍シミュレーション環境でのエージェントの動作を評価するためのハーネスと Civilization Engine の統合が含まれます。
The deepest insight of this work is that evaluation infrastructure is not separate from governance infrastructure — it is governance infrastructure. The metrics an organization chooses to measure, the thresholds it sets for acceptance, and the processes it uses to update evaluation criteria are all expressions of organizational values. The MARIA OS Evaluation Harness makes these choices explicit, auditable, and governed by the same decision pipeline that governs the agents themselves.