1. はじめに
アクションルーターインテリジェンス理論に関する関連論文は、ルーティングはアクション制御の問題であり、テキスト分類の問題ではないという理論的基礎を確立しました。正式な定義 R: (コンテキスト × 意図 × 状態) → アクションは、キーワードとセマンティック ルーティングを包含しながら、構成的なゲートの統合と責任の保持を可能にすることが証明されました。しかし、実装のない理論は建物のない建築です。
この論文はそのギャップを埋めるものです。 MARIA OS 内に展開された完全な Action Router 実装を示し、理論論文で未解決のままだった 3 つの疑問をカバーします。まず、ルーティング トリプル (コンテキスト、インテント、状態) は生のシステム入力からどのように構築されるのでしょうか? Intent Parser レイヤーは、コンポーネントごとに具体的な抽出パイプラインを定義することでこれに答えます。次に、アクション リゾルバーは、数千の登録済みアクションの中からリアルタイムでどのように選択するのでしょうか? O(log|A|) アクションの選択に MARIA 座標構造を利用する階層検索アルゴリズムで答えます。第三に、システムは時間の経過とともにどのように改善されるのでしょうか?私たちは再帰的自己改善をオンライン学習問題として形式化し、収束の保証を証明します。
1.1 アーキテクチャの概要
Action Router は 3 つのレイヤーで構成されており、それぞれのレイヤーには明確に定義されたインターフェイスがあります。
| Layer | Name | Input | Output | Latency Budget |
|---|---|---|---|---|
| L1 | Intent Parser | Raw input x + session metadata | (Context C, Intent I) | ≤ 12ms |
| L2 | Action Resolver | (C, I, S) triple | Action a ∈ A_feasible | ≤ 10ms |
| L3 | Gate Controller | Action a + risk assessment | Gated execution envelope | ≤ 5ms |
合計レイテンシ バジェットは 27 ミリ秒で、P99 の目標である 30 ミリ秒に対して 3 ミリ秒の余裕が残っています。各層は独立して展開可能であり、水平方向に拡張可能です。これらのレイヤーは、MARIA OS SDK で定義された型付きインターフェイスを介して通信し、あるレイヤーへの変更が他のレイヤーを破壊しないようにします。
1.2 設計原則
3 つの原則が実装の指針となります。(1) 分類なし、制御のみ — どのレイヤーもカテゴリ ラベルを生成しません。すべての出力は構造化データまたは実行可能なアクションのいずれかです。 (2) デフォルトでフェールクローズ — いずれかのレイヤーが信頼性の高い出力を生成できない場合、リクエストはデフォルトのハンドラーにルーティングされるのではなく、人間によるレビューにエスカレーションされます。 (3) 構築によって観察可能 — すべてのレイヤーが、入出力ペア、信頼スコア、タイミング データを含む構造化テレメトリを発行し、再帰学習ループを可能にします。
2. レイヤー 1: インテントパーサー
2.1 コンテキスト抽出パイプライン
インテント パーサーは、次の 3 つのソースからコンテキスト C を構築します。(a) 認証セッションから取得されたユーザーの MARIA 座標と権限レベル。 (b) 現在のインタラクション内での以前のルーティング決定とその結果を含むセッション履歴。 (c) 利用可能な措置を制限する可能性のあるアクティブな組織ポリシー（監査期間中の返金の凍結など）。コンテキスト抽出は決定論的かつルールベースであり、ML 推論は必要ありません。
すべての入力がメモリ内キャッシュ (セッション キャッシュ、ポリシー キャッシュ、MARIA 座標レジストリ) から利用できるため、コンテキスト抽出は 2 ミリ秒未満で完了します。
2.2 意図抽出モデル
インテント抽出は、生のテキスト x とコンテキスト C を構造化されたインテント I に変換します。キーワード抽出とは異なり、インテント抽出では 4 つのフィールド構造が生成されます。
ゴール フィールド g ∈ G は、MARIA ユニバースに固有の有限ゴール分類法から描画されます。目標はキーワードではなく、構造化された仕様です。たとえば、goal =solve_multi_issue(issues=[contract_cancellation,refund_processing,compliance_verification]) は、3 つのサブコンポーネントを持つ複合目標を指定します。制約セットは、どのアクションが受け入れられるかを制限します (たとえば、「払い戻しは 10,000 ドルを超えてはなりません」)。優先度は、ユーザーが表明または推測した優先度を反映する連続スコアです。緊急度は、コンテキスト信号 (SLA タイマー、エスカレーション履歴、ユーザー ロール) によって決定される個別のフィールドです。
2.3 軽量の意図分類子
インテント抽出モデルは意図的に軽量化されており、組織データに基づいて微調整された 1,200 万のパラメーターを備えた 2 層トランスフォーマー エンコーダーです。 (a) レイテンシー: 7B パラメーター モデルは推論に 40 ～ 80 ミリ秒を必要とし、レイテンシー バジェット全体を消費するため、意図の抽出には大規模な言語モデルを避けます。 (b) 決定論: 大規模なモデルは、監査ログを複雑にする非決定的な出力を示します。 (c) 組織の特異性: 50,000 のラベル付き組織リクエストに基づいて微調整された小規模モデルは、ドメイン固有のインテント抽出において汎用の大規模モデルよりも優れたパフォーマンスを発揮します。
インテント分類器は、単一の GPU で 8ms の P99 推論レイテンシで、保持された組織データに対して 94.2% の精度を達成します。 2 ミリ秒のコンテキスト抽出と組み合わせると、レイヤー 1 は余裕を持って 12 ミリ秒の予算内で完了します。
2.4 曖昧さの検出と明確化
インテント分類器の信頼度がしきい値 τ = 0.7 を下回ると、インテント パーサーは推測ではなく明確化プロトコルをトリガーします。明確化プロトコルは、上位 2 つの候補の意図に基づいて構造化された質問を生成します。
このフェールクローズ動作により、不確実なルーターが間違った推測をしたときに発生するエラーの連鎖が防止されます。運用環境では、明確化率はリクエストの 6.8% であり、明確化されたリクエストは 99.1% のルーティング精度を達成しています。
3. レイヤー 2: アクション リゾルバー
3.1 アクションレジストリ
アクション リゾルバーは、事前に登録されたアクション スペース A 上で動作します。各アクションは、前提条件、効果、責任の割り当て、ゲート レベル、コスト関数などの完全な仕様とともに登録されます。レジストリは MARIA 座標によって階層的に編成されます。
ActionRegistry
G1 (Galaxy: Enterprise)
U1 (Universe: Sales)
P1 (Planet: Customer Success)
Z1 (Zone: Retention)
a_101: initiate_retention_offer
a_102: process_cancellation
a_103: escalate_to_manager
Z2 (Zone: Billing)
a_201: process_refund
a_202: adjust_invoice
U2 (Universe: Legal)
P1 (Planet: Contracts)
Z1 (Zone: Review)
a_301: initiate_contract_review
a_302: flag_compliance_issueこの階層構造により、検索パスを Galaxy → Universe → Planet → Zone → Actions と絞り込むことで、O(log|A|) アクションの検索が可能になります。 |A| を持つ一般的な企業の場合= 500、フラット リニア スキャンの 500 と比較して、検索訪問数は最大 4 レベル × レベルあたり 5 ノード = 20 ノードになります。
3.2 前提条件フィルタリング
ルーティング トリプル (C、I、S) が与えられると、アクション リゾルバーはまず前提条件を評価して実行可能なアクション セットを計算します。
ここで、A_scope は、ユーザーの権限レベルによって決定される MARIA 座標スコープ内のアクションのサブセットです。座標 G1.U1.P1.Z1 を持つユーザーは、そのゾーン (昇格されたアクセス許可が付与されている場合は親スコープ) に登録されたアクションにのみアクセスできます。前提条件の評価は、スレッド プールを使用して実行可能な候補セット全体で並列化され、20 ～ 50 アクションの一般的なスコープ サイズの場合、3 ミリ秒未満で完了します。
3.3 効果に基づくアクションのランキング
リゾルバーは、実行可能なアクションの中で、予測される効果の質、つまりアクションの予測結果がユーザーが指定した目標にどの程度一致するかによって候補をランク付けします。
距離関数 d は、テキストの埋め込みではなく、構造化された状態表現に作用します。たとえば、目標が 3 つのサブ問題を含む replace_multi_issue である場合、 d は、アクションの予測効果によって対処されるサブ問題の数を、緊急度によって重み付けしてカウントします。この構造化された距離の計算により、意味的には似ているが操作的には異なるアクションが同様のスコアを受け取る埋め込み混同問題が回避されます。
3.4 複合アクションの構成
複合インテントを満たす単一のアクションがない場合、リゾルバーは複数のアクションをアクション プランに組み立てます。
構成では、貪欲なセットカバー アルゴリズムを使用します。各ステップで、最も満たされていない目標コンポーネントをカバーする効果を持つアクションを選択します。貪欲なアルゴリズムは、サブモジュールの目標カバレッジに対して (1 - 1/e) の近似比を達成します。これは、多項式時間で最適であることが証明されています。実際には、複合インテントには平均 2 ～ 3 のアクションが必要で、合成は 2 ミリ秒未満で完了します。
4. レイヤ 3: ゲート コントローラ
4.1 リスク評価
ゲート コントローラーは、選択されたアクション (またはアクション プラン) を受け取り、ゲート レベルを決定するリスク スコアを計算します。リスク評価では、次の 3 つの要素を組み合わせます。
ImpactScore は、アクションの影響の大きさ (財務額、影響を受けるエンティティの数、状態変化の範囲) を測定します。 ReversibilityScore は、アクションをどの程度簡単に元に戻せるかを測定します (完全に元に戻せる = 0、部分的に元に戻せる = 0.5、不可逆 = 1.0)。 ConfidenceGap は、ルーティング決定における不確実性 (最上位のアクションと 2 位のアクションに対するアクション リゾルバーの信頼度の差) を測定します。 ConfidenceGap が高い場合は、ルータが不確実であることを示しており、追加の監視が必要です。
4.2 ゲートレベルの割り当て
リスク スコアは、構成可能なしきい値を通じてゲート レベルにマップされます。
| Risk Score | Gate Level | Execution Mode | Expected Latency |
|---|---|---|---|
| [0, 0.3) | Level 0: Auto-Execute | Immediate execution, async audit log | 0ms (fire-and-forget) |
| [0.3, 0.6) | Level 1: Soft Review | Execute immediately, flag for retrospective review | 0ms + async review |
| [0.6, 0.8) | Level 2: Human Review | Queue for human approval before execution | Minutes to hours |
| [0.8, 1.0] | Level 3: Escalation | Route to senior decision-maker with full context bundle | Hours to days |
しきい値は MARIA Universe ごとに構成できるため、さまざまなビジネス ユニットがリスク許容度を調整できます。高リスクのトレーディング デスクはレベル 2 のしきい値を 0.8 (積極的) に設定し、コンプライアンス部門はレベル 2 のしきい値を 0.4 (保守的) に設定する可能性があります。
4.3 実行エンベロープの構築
ゲート コントローラーは、アクションを実行エンベロープ (実行と監査に必要なものすべてを含む構造化パケット) にラップします。
実行エンベロープは、一度構築されると不変になります。これは、アクションがディスパッチされる前に MARIA OS 監査ログに保存されます。 TTL (存続時間) フィールドにより、構成可能なウィンドウ内で承認されなかったゲート アクションが自動的に期限切れになり、要求元に通知され、変更されたシステム状態で古いルーティング決定が実行されるのを防ぎます。
5. 再帰的な自己改善
5.1 フィードバックループ
Action Router は、実行結果をルーティングの重みに結び付けるフィードバック ループを通じて継続的に改善されます。すべてのアクションが完了 (または失敗) した後、結果が記録されます。
結果レコードには、アクションが成功したかどうか、元の意図をどの程度満たしたか、所要時間はどれくらいか、予期しない副作用が発生したかどうかが記録されます。この結果データは、アクション リゾルバーの重み更新とゲート コントローラーのしきい値キャリブレーションという 2 つの学習メカニズムにフィードされます。
5.2 オンライン体重更新
アクション リゾルバーは、アクションの選択にバイアスをかける重みベクトル w ∈ ℝ^{|A|} を維持します。結果 o_t を観察した後、累乗勾配アルゴリズムを使用して重みが更新されます。
ここで、ℓ_t(a) は時間 t でのアクション a によって発生する損失 (ゴール距離、コスト、失敗ペナルティを組み合わせたもの)、η は学習率、Z_t は正規化定数です。この乗法更新には、次の 3 つの望ましい特性があります。(a) どのアクションにも重みを 0 に割り当てることはありません (探索は保存されます)。 (b) 後から考えると、レート O(√T) で最良の固定アクションに収束します。 (c) 計算的には自明です (更新ごとに O(|A|))。
5.3 収束解析
定理 1 (再帰的改善収束)。 学習率 η = √(ln|A| / (2T)) による累乗勾配更新では、アクション ルーターの累積損失は次の条件を満たします。
|A| の場合= 500、T = 30,000 (1 日あたり 1,000 件の決定で約 30 日の実稼働ルーティング)、決定ごとの平均後悔は √(2 · 30000 · ln 500) / 30000 ≈ 0.018 です。これは、ルーターが 30 日後に最適な固定ポリシーの 1.8% 以内にあることを意味します。これは、観測された精度が 93.4% から 97.8% に +4.4% 向上したことと一致しています。
5.4 ゲートしきい値の校正
ゲート コントローラーのリスクしきい値も再帰学習によって調整されます。私たちはベイジアン アプローチを使用します。各しきい値の事前値は組織のポリシーによって設定され、事後値は観察された偽陽性 (不必要にゲートされたアクション) と偽陰性 (ゲートされていないアクションが害を引き起こす) 率に基づいて更新されます。
非対称重み α_FP および α_FN は、偽陽性 (不必要な遅延) と偽陰性 (制御されていないリスク) の相対コストを反映します。実際には、α_FN ≫ α_FP は 5 ～ 10 倍です。これは、システムが保守的であることを意味します。つまり、真のリスクを見逃さないように、不必要なゲートを許容します。
6. 100 を超えるエージェント展開のためのスケーリング アーキテクチャ
6.1 スケーリングの課題
Enterprise MARIA OS の展開には、それぞれが独自のアクション スペースを持つ、複数のユニバースにわたる 100 以上のエージェントを同時に関与させることができます。単純な集中ルーティングではボトルネックが発生します。すべてのルーティング決定は、アクション スペース全体を検索する必要がある単一のリゾルバーを介して行われます。 1 秒あたり 10,000 リクエストおよび |A| の場合= 2,000、集中型アプローチは 30 ミリ秒の遅延目標を超えています。
6.2 座標ベースのシャーディング
Action Router を MARIA 座標でシャーディングします。各ユニバースは、その組織スコープ内のすべてのルーティング決定を処理する専用のルーティング パーティションを受け取ります。
各パーティションは、独自のアクション レジストリ、重みベクトル、およびゲートしきい値を維持します。クロスユニバース ルーティング (まれに、リクエストの約 3%) は、適切なパーティションに委任する前にターゲット ユニバースを決定する軽量メタルーターによって処理されます。
6.3 階層型アクションキャッシュ
各パーティション内で、3 レベルのアクション キャッシュを維持します。
- L1 キャッシュ (ゾーンローカル): ゾーンごとに最も頻繁に選択された 10 個のアクション。マイクロ秒未満のアクセスでメモリ内に保存されます。キャッシュ ヒット率: 72%。
- L2 キャッシュ (プラネットローカル): プラネットごとに最も頻繁に選択された 50 個のアクションが、共有メモリ領域に保存されます。キャッシュヒット率：91％（L1との累計）。
- L3 キャッシュ (ユニバース全体): Redis クラスターに保存される、ユニバースの完全なアクション レジストリ。キャッシュ ヒット率: 100% (定義上)。
キャッシュ階層により、一般的なケースでは平均アクション ルックアップが 5 ミリ秒 (完全なレジストリ検索) から 0.8 ミリ秒 (L1 ヒット) に短縮されます。キャッシュの無効化はイベント駆動型です。アクションの前提条件が変更されると (エージェントがオフラインになるなど)、関連するキャッシュ エントリが MARIA OS イベント バスを介してただちに無効化されます。
6.4 スループット分析
4 つの Universe パーティションがあり、それぞれが 2,500 rps を処理し、キャッシュ階層によりリクエストごとのレイテンシーが 14 ミリ秒 (P50) に短縮されるため、システムは 28 ミリ秒の P99 レイテンシーで 10,000 rps を維持します。ボトルネックはアクション検索からインテント抽出 (レイヤー 1) に移行します。ロード バランサーの背後に複数のインテント分類子のレプリカをデプロイすることでこれに対処します。
7. デシジョンパイプラインステートマシンとの統合
7.1 意思決定パイプライン
MARIA OS 意思決定パイプラインは、6 段階のステート マシンを実装します。
proposed → validated → [approval_required | approved] → executed → [completed | failed]MARIA OS におけるすべての決定は、このパイプラインを通過します。ルーティングされたアクションによって決定が作成されるため、アクション ルーターはパイプラインとインターフェイスする必要があります。ルーターによって選択されたアクションは「提案された」状態でパイプラインに入り、実行前に適切なステージを通過する必要があります。
7.2 プロダクトオートマトン
アクション ルーター状態とデシジョン パイプライン状態の製品オートマトンとして統合を形式化します。 Q_R = {idle、parsing、resolved、gating、dispatched} をアクションルーターの状態とし、Q_P = {projected、validated、approval_required、approved、executed、completed、failed} をパイプラインの状態とします。積オートマトン Q = Q_R × Q_P は |Q_R| を持ちます。 × |Q_P| = 5 × 7 = 35 州、そのうち 18 州に到達可能:
網羅的な列挙によって、(MARIA OS valid_transitions テーブルで定義されている) 12 個の有効なパイプライン遷移すべてがルーティング層から到達可能であることを検証します。これは、アクション ルーターがパイプラインを通じて有効な決定を実行できることを意味します。デッド ステートは存在しません。
7.3 遷移マッピング
各ルーティング結果は、特定のパイプライン遷移にマップされます。
| Router Outcome | Pipeline Transition | Condition |
|---|---|---|
| Action selected, gate = L0 | proposed → validated → approved → executed | Auto-execute path |
| Action selected, gate = L1 | proposed → validated → approved → executed | Execute + async review |
| Action selected, gate = L2 | proposed → validated → approval_required | Queue for human approval |
| Action selected, gate = L3 | proposed → validated → approval_required | Escalate to senior |
| No feasible action | proposed → failed | Fail-closed |
| Ambiguous intent | (no pipeline entry) | Clarification loop |
7.4 アトミック性とロールバック
製品オートマトンは、ルーティングとパイプラインの遷移がアトミックであることを保証します。ルーティングからパイプラインへのハンドオフ全体が成功するか、システムがルーティング前の状態にロールバックします。これは、2 フェーズ コミット プロトコルを使用して実装されます。フェーズ 1 では、実行エンベロープを構築し、パイプライン スロットを予約します。フェーズ 2 では、アクションをディスパッチし、パイプラインの状態を進めます。フェーズ 2 が失敗した場合 (ターゲット エージェントが利用できないなど)、フェーズ 1 がロールバックされ、更新された状態でルーティングの決定が再試行されます。
8. 生産指標とベンチマーク
8.1 導入構成
ベンチマークは、次の構成のシミュレートされた運用環境で実行されます。4 つの MARIA ユニバース (販売、法務、コンプライアンス、オペレーション)、12 のプラネット、48 のゾーン、127 のアクティブ エージェント、523 の登録アクション、およびピーク時の平均リクエスト レートは 1 秒あたり 10,000 のルーティング決定です。評価期間は 30 日間で、合計 860 万件のルーティング決定が行われます。
8.2 経時的な精度
| Day | Routing Accuracy | Clarification Rate | Fail-Closed Rate |
|---|---|---|---|
| 1 | 93.4% | 6.8% | 1.2% |
| 7 | 95.1% | 5.4% | 0.9% |
| 14 | 96.3% | 4.7% | 0.7% |
| 21 | 97.2% | 4.1% | 0.5% |
| 30 | 97.8% | 3.6% | 0.4% |
精度の向上は、理論上の O(√T) 収束率に従います。実稼働データの微調整によって意図分類子が改善されると、明確化率は低下します。操作中に特定されたエッジ ケースをカバーするためにアクション レジストリが拡張されると、フェールクローズ率が低下します。
8.3 遅延プロファイル
| Component | P50 | P90 | P99 | P99.9 |
|---|---|---|---|---|
| Intent Parser (L1) | 7ms | 10ms | 12ms | 18ms |
| Action Resolver (L2) | 4ms | 7ms | 10ms | 15ms |
| Gate Controller (L3) | 2ms | 3ms | 5ms | 8ms |
| Total (end-to-end) | 14ms | 22ms | 28ms | 38ms |
P99 の合計 28 ミリ秒は、目標の 30 ミリ秒以内です。 P99.9 の 38 ミリ秒は目標を超えていますが、発生率は 1,000 リクエストに 1 件であり、重要なリクエストが優先キュー処理を受けるエンタープライズ ワークロードには許容可能です。
8.4 スケーリング効率
| Metric | 1 Partition | 2 Partitions | 4 Partitions | 8 Partitions |
|---|---|---|---|---|
| Max RPS | 3,200 | 6,100 | 10,400 | 18,700 |
| P99 Latency | 28ms | 27ms | 28ms | 29ms |
| Scaling Efficiency | 1.0x | 0.95x | 0.81x | 0.73x |
8 つのパーティションでは、パーティション間のルーティング オーバーヘッド (ユニバースの境界を越えるリクエストの 3%) により、スケーリング効率が低下します。ほとんどのエンタープライズ展開では、4 つのパーティションで、ほぼ線形のスケーリングで十分なスループットが提供されます。
8.5 ベースラインとの比較
| Metric | Keyword Router | Semantic Router | Action Router (Day 1) | Action Router (Day 30) |
|---|---|---|---|---|
| Accuracy | 62.1% | 74.3% | 93.4% | 97.8% |
| P99 Latency | 12ms | 89ms | 28ms | 26ms |
| Gate Compliance | 71.3% | 76.8% | 99.5% | 99.7% |
| Audit Completeness | 41.2% | 55.1% | 100% | 100% |
| Responsibility Attribution | 34.8% | 48.3% | 97.1% | 98.4% |
9. ディスカッション
9.1 実装から得た教訓
3 つの実装上の教訓が際立っています。まず、意図分類子のトレーニング データの品質は、モデルのサイズよりも重要です。 50,000 の高品質な組織例でトレーニングされた 12M パラメーター モデルは、ドメイン固有のインテントに関して 7B パラメーターの一般モデルよりも 11 パーセント ポイント優れています。これは、組織の意図には、一般的なモデルがトレーニングされていない分布特性 (複合目標、権限依存のセマンティクスなど) があるためです。
次に、アクション レジストリは生きた成果物であり、継続的なキュレーションが必要です。 30 日間の評価を通じて、23 の新しいアクションが登録され、8 つのアクションが廃止され、41 のアクションの前提条件が更新されました。再帰学習ループは、既存のアクションと高い信頼度で一致しないリクエストのクラスターを検出することで、新しいアクションの必要性を特定します。
第三に、フェールクローズ設計はユーザーの信頼を構築するために不可欠です。導入の初期段階では、6.8% の解明率が弱点 (「システムが私を理解していない」) として認識されていました。自動ルーティングされたリクエストの 93.4% に対して、明確化されたリクエストでは 99.1% のルーティング精度が達成されたことをユーザーが観察した後、明確化のプロンプトは肯定的なシグナル (「システムが慎重である」) になりました。 30 日目までに、明確化されたリクエストのユーザー満足度スコアは、自動ルーティングされたリクエストのユーザー満足度スコアを 8 ポイント上回りました。
9.2 制限事項
Action Router には 3 つの既知の制限があります。まず、アクション レジストリには先行投資が必要です。各アクションは、前提条件、効果、および責任の割り当てを指定して指定する必要があります。プロセスの文書化が不十分な組織の場合、この登録作業は多大な労力を要する可能性があります。当社では、既存のワークフローを監視し、人間によるレビューのためのアクション定義を提案する自動検出ツールを使用してこれを軽減します。第 2 に、12M パラメータの意図分類子は、トレーニング データで表現されていない新しいリクエスト タイプにうまく一般化できない可能性があります。私たちは、明確化プロトコルと、蓄積された生産データの定期的な再トレーニングを通じて、この問題に対処します。 3 番目に、座標ベースのシャーディング戦略は、クロスユニバース ルーティングがまれであることを前提としています。部門間のコラボレーションが頻繁に行われている組織では、3% の仮定が当てはまらない可能性があり、より洗練されたメタルーティング層が必要になります。
10. 結論
この文書では、MARIA OS に実装された Action Router の完全なエンジニアリング アーキテクチャについて説明しました。 3 層スタック (インテント パーサー、アクション リゾルバー、ゲート コントローラー) は、アクション ルーター インテリジェンス理論の理論的フレームワークを実稼働対応のシステムに変換します。各レイヤーには、明確に定義されたインターフェイス、レイテンシ バジェット、および独立したスケーラビリティがあります。
再帰的な自己改善メカニズムは、アクション ルーターが静的なシステムではなく、学習するシステムであることを示しています。 30 日間で +4.4% の精度向上は、証明可能なリグレス限界を備えたオンライン凸型最適化の原則的な適用によって達成されており、導入期間を長くすることでさらなる利益が得られ、組織にとって最適なルーティング ポリシーに漸近的に近づくことを示唆しています。
スケーリング アーキテクチャは、アクション レベルのルーティングが本質的にキーワード ルーティングよりも高価ではないことを証明しています。座標ベースのシャーディングと階層キャッシュにより、アクション ルーターは 30 ミリ秒未満の P99 レイテンシで 10,000 rps を維持します。これは、P99 でのセマンティック ルーティングよりも 3.2 倍高速なパフォーマンスであり、キーワード ルーティングと競合すると同時に、劇的に高い精度と責任コンプライアンスを実現します。
製品オートマトンとして形式化された意思決定パイプライン ステート マシンとの統合により、すべてのルーティング決定がガバナンス インフラストラクチャにシームレスに接続されることが保証されます。ルーティングされたアクションはパイプラインをバイパスしません。ルーターから到達できないパイプライン状態はありません。ルーティング層とガバナンス層は、ボルトで結合された別個のシステムではありません。それらは単一の構成アーキテクチャです。
アクション ルーターは、インテリジェント ルーティングの最後の言葉ではありません。今後の作業には、複数ステップの計画 (単一のアクションではなくアクション シーケンスへのルーティング)、敵対的な堅牢性 (ルーティングを操作しようとするプロンプト インジェクション攻撃への耐性)、MARIA ギャラクシー全体でのフェデレーション ラーニング (プライベート データを共有せずに、組織の境界を越えてルーティングの知識を共有する) が含まれます。しかし、ルーティングは単語を分類するのではなく、アクションを制御する必要があるという核心的な洞察は、将来のすべての進歩の基礎となります。
参考文献
1. さくら / 凡銀館 (2026) AI ルーティングがキーワード ベースではなくアクション ベースである必要がある理由。 note.com。 2. シャレフ・シュワルツ、S. (2012)。オンライン学習とオンライン凸最適化。 ML の基礎と傾向、4(2)、107-194。 3. アローラ、S. 他。 （2012年）。乗算重み更新メソッド。 コンピューティング理論、8(1)、121-164。 4. ホップクロフト、J.E. 他(2006)。 オートマトンの理論、言語、計算の紹介。第 3 版、ピアソン。 5. MARIA OS 技術文書 (2026)。アクションルーター実装ガイド、v1.0。 6. MARIA OS 技術文書 (2026)。デシジョン パイプライン ステート マシン仕様、v2.1。