• エージェント向け skill（ + スクリプトのパッケージ）を「ドキュメントとしてスキャンする」のではなく、実際にエージェントに実行させて価値を測る評価フレームワーク ACES の提案。実装は NVIDIA SkillEvaluator として OSS 公開

• skill は Claude Code / Codex / Cursor 等で共通化が進み、社内リポジトリや公開レジストリに数千個ある。しかしレビューゲートは4クラスすべて静的スキャン（構造チェック / LLM-as-Judge / linter / セキュリティスキャナ）で、「本番と同じモデル・サンドボックス・採点条件で、この skill は本当にタスク遂行を助けるのか」という配備判断の問いに誰も答えていない

• 実際、145 本の実 skill を測ると frontmatter 契約はほぼ形骸化（99.3% が 未宣言）しているのに skill は普通に動く。さらに構造スコアと LLM-judge スコアは Spearman ρ=0.14 でほぼ無相関 — スキャン同士ですら別のものを測っている

• スキャンを通過しても実行時に失敗する 5つの失敗モード: (a) 発見されない / (b) 誤ったスクリプト・引数で呼ぶ / (c) 正しい出力を誤って解釈・報告 / (d) 同居 skill と衝突 / (e) モデル更新でのサイレントな劣化 — いずれも skill 単体からは観測できない。論文はこれを「 でコンパイルが通っても意図どおり動くとは限らない」と喩える

• 同一タスク・同一 harness・同一 workspace・同一 scorer で「skill あり / なし」のペア実行を行い、reward の差分 = Skill Lift として skill の限界的寄与を測る。baseline 側にも decoy skill を置き、発見・ルーティングの負荷を両条件で揃える

• トラジェクトリは ATIF（harness 横断の共通 JSON トレース形式）に正規化し、6つのデフォルト指標で採点: 決定的な / / + LLM/RAGAS ジャッジの / /

• 評価データセット は skill リポジトリに同梱し、CI で skill 変更のたびに実行 — 「 は skill の 」という evaluation-native な開発フローを提案

• スキーマは6フィールドだけ: / （ユーザーの質問）/ （期待される skill。ネガティブケースでは null）/ （任意）/ （参照回答）/ （エージェントが示すべき観測可能な挙動の順序付きリスト）

• 3つの設計原則:
• ① Write once, evaluate everywhere（skill ごとに1つの evaluation contract が全レイヤ・全エージェントを駆動）
• ② Differential measurement（品質は比較的性質 — 変えるのは対象 skill の有無だけ）
• ③ Developer-guided evaluation（自動生成はブートストラップであって oracle ではない。 の著者意図が LLM 生成物に常に優先）

• skill の価値は content 寄与（使うと決めた後の手順の質）と discovery / routing 寄与（複数候補から選ばれるか）に分解できる。対象 skill だけを置く isolation と decoy 同居の group の2モードで測り、差分が routing premium — ゼロ近傍なら「名前と説明が隣接 skill と差別化できていない」という実行可能なシグナルになる

• ⚠️ ただし routing premium は手法として定義・提供されているものの、論文の実証評価に per-skill の実測値は報告されていない（本番 947 ケースの isolation / group 内訳も非明示）。手法の提案 ≠ 全機能の実証

• 代わりに報告されているのが routing ストレステスト（25 variant、本番集計とは別枠）: 可視 skill 1〜20 では lift 0.133〜0.149 で安定だが wall time は 258→451 秒に増加。可視 50 で pass rate 0.55 まで低下し wall time 1,290 秒（約3倍超） — 「とりあえず全部載せる」は routing コストとして跳ね返る

• 平均 composite Skill Lift = +0.2134（95% CI [0.1967, 0.2301]）、72.8% のケースで正。つまり skill は総じて効く（絶対値では with-skill 0.7460 vs baseline 0.5326。符号分布は 正689 / ゼロ171 / 負87、中央値 0.1717 — 外れ値に押し上げられた平均ではない）

• ただし最大の伸びは最終回答の正しさ（accuracy +0.143）ではなく、プロセス指標: skill execution +0.326 / behavior check +0.298 / skill efficiency +0.276 — 「skill を読んだか・ワークフローに従ったか」はドキュメントスキャンでは原理的に観測できない信号

• negative lift はデバッグ信号: 947 中 87 ケースが負。トラジェクトリを見ると「実行の不安定性」と「clean negative（発見はしたが検証を飛ばした・余分なツールコールを消費した）」の2クラスに分かれ、「発見されなかった」と「発見されたが誤用された」を分離できる — 打つ手（description 改善 vs 手順本文の改善）が変わる

• 静的スコアはランタイム証拠にならない: 構造スコアと live lift の相関は ρ = −0.018、LLM-judge スコアとも ρ = −0.027（いずれもゼロと区別不能）。静的レビュー満点・accuracy 1.0 の skill でも、中間成果物にシークレット様文字列が残っていたケースあり

• lift は harness 依存で大きく変わる（OpenCode +0.36 〜 Terminus-2 +0.09）。またモデルが強くなると baseline が上がるため lift は縮む（Codex で GPT-5.2→5.5 のスイープ: +0.09→+0.05）→ モデル更新のたびに再評価が必要

• 静的スキャンとライブ評価は「精度の違い」ではなく観測対象の違い。スキャンは authoring 品質のゲートに使い、デプロイ判断はペア実行で測る

• 測定単位を「エージェント」でなく「skill」にする — 同じ skill でも harness 次第で +0.36〜+0.09 まで変わる

• プロセス指標を必ず含める — accuracy だけ見るとワークフロー遵守の改善（+0.326）を半分以下に過小評価する。逆に「skill を入れれば速くなる」は 42% しか当たらない

• lift の低下 ≠ skill の劣化。モデルが強くなると baseline が上がって lift は縮む（GPT-5.5 で +0.11→+0.05）ので、絶対スコアと併読し、モデル更新後に定期再評価する

• workspace に skill を置きすぎない: 可視 skill 20→50 で pass rate 0.55 に低下、wall time 約3倍。カタログが大きい組織では可視スキルの絞り込み自体が性能施策

• コストは二層で設計: スキャンは毎コミット、ライブペア評価はリリース候補・高リスク skill・レビュアー要求時

• 1億人以上のユーザーを抱える銀行Nubankのカスタマーサポート（CS）AIエージェントの評価パイプライン事例紹介

• コーディング支援や検索エージェントと違い、CSエージェントには特有の難しさがある。論文は次の5点を挙げる。
• 品質基準が高い。 銀行で1回の誤対応が顧客の解約や損失に直結する。
• 機微なデータを扱う。 残高・取引履歴・住所などプライバシー規制の対象データを扱う。
• ツールセットが狭く深い。 汎用エージェントと違い、5〜15個程度のドメイン特化ツールだけを使うが、その中でのエッジケースは非常に多様。
• 人間への優雅な引き継ぎが必須。 自動化が失敗したら、会話の文脈を保ったまま人間のオペレーターに渡す必要がある。

• 評価駆動開発フレームワーク



• 「速いループ」の評価が信頼できるなら「遅いループ」を待たずに改善を速く回せる。そのための工夫を入れているフレームワーク。
• コンテキストエンジニアリング
• プロンプトを部品ごとにバージョン管理する
• Instructions： エージェントの役割・振る舞いのルール・コンプライアンス制約。
• Routines： 人間向けの業務マニュアル（SOP）を、エージェントが実行できる手順に変換したもの。例えば「カード配送調査ルーティン」は「① 挨拶して状況を把握 → ② 配送データ取得 → ③ 住所タイプ別の質問 → ④ 未解決なら再発行を提案」という順序で組まれる。
• Macros： よくある場面用の定型応答テンプレート（ゼロから文章を組み立てず、自然な言い換えは許す）。
• Tool定義とスクラッチパッド： 各ツールは名前・入力スキーマ・出力形式・呼び出し条件を明記して独立に管理する。スクラッチパッド（作業記憶）は会話中に集めた情報を保持し、同じツールを無駄に呼び直さないようにする。
• 各部品が独立にバージョン管理されているので、「v3のInstructions + v1のRoutines + v2のTools」のように組み合わせを選んで新しい設定を作れる。これにより、プロンプト全体を書き直すのではなく、失敗の原因になった一部品だけをピンポイントで直す、という開発ができる。
• LLM Judgeの信頼性担保
• Judgeプロンプト改善手順
1. ドメイン知識を持つ人間のアナリスト3人が、実会話サンプル（数百件）に対して2値ラベル（成功/失敗など）と、その理由を説明するテキストを付与する。最終ラベルは多数決。
2. この人間ラベル付きデータを使い、GEPAでLLM Judge用のプロンプトを最適化する。ベースモデルにGPT-4.1-mini、批評・改善役（reflection model）にGPT-5.1を使い、約500イテレーション回す。人間が書いた「なぜその判定にしたか」という自由記述の理由も最適化のヒントとして与える。
3. 最適化後のJudgeプロンプトを、7種類の異なるLLM（GPT-4.1系、GPT-4o系、GPT-5、o3系）に適用し、モデル間の判定の一致度（Cohen's κ）を比較する。
💡
Cohen's κ（カッパ係数）: 2人（または2つのモデル）の判定がどれだけ一致するかを、偶然の一致率を差し引いて測る指標
κ = (p_0 - p_e) / (1 - p_e) （po：観測された一致率、pe：偶然による期待一致率）
κ が 0.8 を超えると「高い一致度」とされ、その評価ラベルは信頼できるとみなせる。逆に κ が0に近い、または負であれば、評価者間でほぼ合意がなく、その評価基準（ルーブリック）自体が曖昧である可能性が高い。
改善の具体例
• このJudgeを使って、E1（エージェントの再発行判断ミス）〜E5（回答の完結性）まで5種類の評価カテゴリでプロンプトを最適化した結果、正解率はすべてのタスクで多数派ベースライン・手書きプロンプトの両方を上回った

• 評価
• オフラインで評価が改善すると、実際にオンラインの顧客満足度・自動化率が改善するのか
• カード配送エージェントでオフライン評価で改善した結果、オンラインのNPSも改善
• オフラインの改善幅とオンラインの改善幅が相関

• ドメインへの汎化



• 概ねオンライン評価が改善傾向
• △人間tNPS差（AIエージェントのtNPS − 熟練human agentのtNPS）はマイナス傾向。特にDebt Management（負債管理）は悪い。複雑な多段階の数値推論は難易度高い。

概要

• 実際にプロダクトで使うエージェント・ハーネスをそのままRL環境で使う

• これをHarnessed Agentic RLと呼んでいる

• 1つのrolloutが分岐する問題の対処に焦点を当てている

Harnessed Agentic RL

• 従来のAgentic RLはLLMが環境とトークンを介して相互作用する

• 実際のエージェントはclaude codeのような独自ハーネスがあり、ハーネス側でコンテキスト圧縮やtool call, sub agentなどを管理している

• LLM単体の性能を上げるだけでなくハーネスで動くLLMの性能を上げたいという背景がある

• 本フレームワークでは実際のハーネスをもとにrolloutを行い、そのハーネス上で良い振る舞いをするようにLLMのpolicyをRLする

• ※環境とハーネスはここでは別概念として扱う

システム設計

• Trainer：  と vLLM を実行し、学習サンプルを生成してポリシーを更新する

• API gateway: モデルへのリクエストを中継し、学習データを収集する

• Rollout Controller: エージェントをローカル環境またはKubernetesジョブとして実行する

1つのrolloutが複数の学習サンプルに分割される問題

• sub agentAとsub agentBで与えるコンテキストと軌跡が異なるので軌跡ごとに分ける

• 要約したタイミングでコンテキストが変わるのでその前後で分ける

• LLMが生成したtextを次のターンでtokenizeして渡すとtoken idで見ると1ターン目と2ターン目でズレることがある

• この事象はRLではオフポリシー化を誘発するため本フレームワークではmismatchが発生したら分割するということをやっている

Agent Lightning ⚡ BlogAdopting the Trajectory Level Aggregation for Faster Training

サンプル分割問題への対応

アドバンテージ計算

• GRPOの1グループでrollout1とrollout2が生成されたとする

• rollout内部でサンプル分割が発生したrollout1のadvantageは過大評価されてしまう

• rollout単位でadvantageを計算すべきというのが本論文の主張(つまり右のような分割が発生しても左のようにみなしてadvantageを計算する)

損失の正規化

• バッチで損失計算するときにrolloutの長さや1つのrollout内の学習サンプル数はバラバラ

• 損失計算の粒度としてtoken単位、サンプル単位、rollout単位の3つがありadvantage計算に合わせてrollout単位で損失を計算する方法をとっている

• GLM5系に利用されているslimeもこの方式

• advantage計算をsample単位とrollout単位で行う場合を比較している

• rollout単位の方が報酬は高くなる傾向であることが確認されている

その他工夫

Collocated Async RL

• 同期RLだと全rolloutの完了を待って学習するのが非効率ということで非同期RLが現在は主流

• 完全な非同期RLはrolloutと学習用でGPUを分けてそれぞれを非同期に処理する

• 提案の非同期RLはGPU使用数を節約するためにGPUをrolloutと学習用で分けず交互に利用

• 論文: Beyond Logprobs: A Multi-Signal Confidence Engine for LLM-Based Document Field Extraction

• 投稿: 2026/06/23

• 種別: IJCAI-ECAI 2026 RobustifAI Workshop 採択（Oral）

tl;dr

論点 1: 既存の信頼度は実務の閾値で機能しない

論点 2: Hunter と Mapper の非対称性を信号に変える

論点 3: 単一シグナルではなく 5 系統を分類器で統合する

1. 呼び出し間の不一致（cross-call disagreement）

2. LLM 内部の不確実性

3. OCR の情報

4. 画像品質

5. 空間レイアウト

結果

monoke 感想

• シンプルで納得感のある信頼性推定の方法

• ベースライン手法同士ではそこまで変わらないのを確かめていて興味深い

• 動的かつ部分的な処理による効率化: MoEは、モデル内に「Expert」と呼ばれる多数のサブネットワーク（専門家）を保持し、各トークン（処理の最小単位）の処理時に、その中からごく一部のExpertだけを動的に選択してアクティブにする（ルーティングする）アーキテクチャ。

• パラメータ規模と計算量の両立: 例えば「DeepSeek-V4-Flash」では、各レイヤーに256個のExpertが存在するが、1つのトークンが通過するのはそのうちのわずか6個だけ。これにより、モデル全体のパラメータ数が284B（2840億）という巨大な規模でありながら、1つのトークンの処理時に実際に関与するのは13B（130億）相当に抑えられる。この「疎な活性化（Sparse Activation）」により、巨大モデルの高い表現力を維持したまま、1トークンあたりの計算量を大幅に削減できる

• メモリ・コンテキスト管理: paged KV cache管理や、Radixツリーに基づくプレフィックス再利用（Radix-based prefix reuse）などの洗練された機能をそのまま継承・統合しています1。

• カーネルライブラリの活用: アテンション演算やアテンションスケジューリングには、高性能なコミュニティライブラリである FlashInfer や Flash Linear Attention (FLA) を適宜取り入れています。

• デバイス側キャッシュ制御（Device-side Cache Control）
• 各レイヤーにおいて、1つのGPUカーネルが「重複トークン用のExpertデデュープ（重複排除）」「既存キャッシュテーブルとの比較（ヒット/ミス判定）」「帯域に基づく転送数 の算出」「追い出し対象（Victim）の選定」「論理IDから物理スロットIDへの書き換え」をすべて行います。

• LRUのトラップ回避（1パスによる追い出し候補の発見）
• 通常、LRUキャッシュから複数のスロットを追い出すにはキャッシュ全体を何度もスキャンする必要があります。FreeTokenでは、わずか1パス（Single-pass）のスキャンで「最も最近使われていない（LRU）上位 個の候補スロット」を一度に特定するカスタムGPUカーネルを実装しています4。ミスの転送要求 は、この特定された候補から順に消費されるため、ミス数に関わらず探索コストは常に1パス分で固定されます。

• 統合された転送カーネル（Fused Transfer）
• すべてのExpertバンクが同一の「論理Expert-スロット変換マッピング」を共有するため、デバイス側の一一のインデックスリスト（転送元/転送先）を使って、全Expertバンクに対する非同期DMA転送を1つの固定形状カーネルとして一括で起動できます（不使用スロットは有効カウントでマスク処理）。

• グラフ内の同期とシームレスな制御
• デコードのバッチサイズごとに、安定したピン留め（Pinned）I/Oバッファとタスク記述子が事前に確保されています5。CUDA Graphには「デバイス→ホストへのデータコピー」「ホスト関数（CPU実行用）のサブミットノード」「並行して走るGPU側の処理」「GPU-CPU同期ノード」「ホスト→デバイスへの出力書き戻しコピー」がひとまとめに登録されています5。これにより、Python側からの指示や毎トークンごとのスケジュール同期を一切介さずに、非同期・並列実行を高速にリプレイできます5。

• 常駐型C++ワーカープール（Persistent C++ Thread Pool）
• CPU処理の実体は、マシンの物理コア（Physical Cores）に強固にピン留めされた、常駐型のC++スレッドプールです。CPUワーカー内のカーネルは、ハードウェアに特化したSIMD命令およびインカーネルでの動的脱量子化（Dequantization）を用いてExpertの重みを直接ロード・計算します。これにより、処理をDRAMの最大帯域幅制限（Bandwidth-bound）に張り付かせ、無駄な計算オーバーヘッドを排除した状態で部分的な重み付き出力を計算します。

• FTW（FreeToken Weight）フォーマットの導入: 様々なMoEモデル固有のチェックポイント構造を、レイヤーとExpertのフラットなID（）をリード次元とする、統一されたいくつかの「Expertバンク（Expert Banks）」に正規化します8。事前にこのランタイムに最適なバンク構造へと重みを結合・整理して保存しておく独自形式「FTWフォーマット」を開発しました。

• ゼロ初期化（Zero-initialization）回避とダイレクトI/O
• 起動時にFTW形式を読み込む際、テンソル構成のパースやCPU側での重みの並べ替え（Repacking）は一切不要です8。アライメントされたデータを並列ダイレクトI/O（Parallel Direct I/O）により、ディスクからメモリ上へ直接、正確なサイズに切り出されたホストバンクに一括ロードします。
• さらに、あらかじめ空のメモリバッファを確保してピン留め（DMA可能にする処理）してからロードする従来の手法を改め、「ロード完了後に初めて物理メモリをピン留めする」というアプローチをとっています8。これにより、空メモリの確保時に発生する「OSがギガバイト単位のメモリページをゼロで初期化し、ページフォールトを解決する」という数十秒の余計な待ち時間を完全にスキップし、ディスク読み込み速度（例：NVMe SSDの物理限界である約7GB/sなど）を100%発揮させます。

• ロード時の動的ディスパッチ
• 起動時にハードウェア構成をプロファイリングし、GPUのアーキテクチャやCUDA環境、CPUのSIMD命令セット（AVX512やAMXなど）、物理コアレイアウトを自動検知して、最も最適な計算カーネルを動的にディスパッチしてマッピングします。

• Pure-CPUフォールバックモード
• 一部のOSやドライバのセキュリティ制限により、大容量のホストメモリ（数〜数百GB）をすべてピン留め（DMA登録）できない状況に直面することがあります。その場合、FreeTokenは自動的に「Pure-CPU MoEバックエンド」へフォールバックします。
• このモードでは、全Expert重みは通常の仮想メモリ（Pageable storage）上に置かれ、すべてのルーティング先ExpertがCPU上で実行されます。GPU上には非Expertレイヤーだけを常駐させ、CPU-GPU間はアクティベーションデータ、ルーティングのメタデータ、集計された出力データ（モデルのパラメータに比べて極めて軽量なデータ）のみをやり取りする設計をとることで、最悪の環境であっても推論サービス自体を確実に実行・デプロイできる互換性を担保しています。