AI News HubLIVE
站内改写5 分で読了

AI行動の検証可能な分析フレームワーク

本記事では、Docentが開発した分析計画フレームワークを紹介します。これは、クエリステップとリーディングステップを組み合わせ、人間が各ステップを検証できる透明なパイプラインを提供します。SWE-rebenchベンチマークでのデモでは、報酬ハッキングや不正行為を検出し、詳細な監査証跡と引用に基づく検証を示しています。

ソースHacker News AI著者: mengk

AIエージェントの開発は複雑なデータ分析問題です。エージェントが正しく動作しているかどうかを知るには、ベンチマークスコアだけでなく、その行動の詳細を追跡する必要があります：訓練過程で戦略はどのように変化するか？新しいスキャフォールドのパフォーマンスが低下する理由は？報酬ハッキングはあるか？これらの質問に答えるには、手元のデータセットに合わせた定量的・定性的分析の組み合わせが必要です。

コーディングエージェントはこの作業を加速する可能性がありますが、微妙な間違いを犯しがちです：データを誤って解析したり、不当な仮定をしたり、例を選んで誤解を招くような説明を提示したりします。これらの間違いは最終出力では明らかではありません。結論を信頼するには、それがどのように生成されたかを正確に検証する必要があります。しかし、コーディングエージェントが取ったすべてのアクションをレビューするのは面倒です—重要な方法論の決定が何百行ものログに埋もれてしまいます。

この問題から、私たちは分析計画、すなわちAI行動の検証可能な分析のためのフレームワークを開発しました。分析計画はPython APIで指定され、どのコーディングエージェントでも扱うことができます。実行準備が整うと、人間がすべてのステップを理解し検証できるウェブインターフェースに表示されます。

分析計画には2種類のステップが含まれます：

  • クエリステップ：DQL（DocentのSQLサブセット）を使用してデータをフィルタリング、グループ化、結合します。各ステップはクエリと結果のインタラクティブなテーブルとともに表示されます。
  • リーディングステップ：LLMを使用してクエリステップのデータを分析し、テキスト要約および/または構造化された判断を生成します。LLMによる主張は、そのコンテキスト内の特定の項目への引用が付きます。

これら2つのステップをカスタマイズして組み合わせ、複雑な分析パイプラインを構築できます。リーディングはクエリが生成する任意のデータを受け入れ、クエリは任意のリーディング結果に対して実行できます。各ステップで、結果はそれを生成した正確な計算にトレースされるため、フローを検査、監査、洗練することができます。

実際の動作を見るために、人気のあるソフトウェアエンジニアリングベンチマークでの不正行為の検出をデモンストレーションします。

デモ：SWE-rebenchにおける不審な行動の特定

不正行為は評価結果を解釈する際の一般的な悩みです：モデルはテストをハードコーディングしたり、成功を偽って主張したり、クリーンでない環境を悪用して解答をコピーしたりすることで有名です。不正行為の割合を測定することは、ベンチマークスコアがモデル能力の有効なデモンストレーションをどの程度表しているかを理解するために不可欠です。私たちは約15分で、Docentを使用してSWE-rebench（エージェントがどれだけ最近のGitHub PRを解決できるかを測定するソフトウェアエンジニアリングベンチマーク）での不正事例を発見しました。SWE-rebenchのトレースはこのリンクで表示できます。

  1. コーディングエージェントに知りたいことを説明する

まず、Claude Codeにエージェントの実行を潜在的な不正行為についてスコアリングするように指示します。Docentスキルのおかげで、Claudeは私たちの質問を分析計画に変換する方法を知っています。以下のような短いPythonスクリプトを作成します。

from docent import Docent
client = Docent()

runs = client.query(
COLLECTION_ID,
"SELECT agent_runs.id AS run FROM agent_runs "
"WHERE CAST(metadata_json->'scores'->>'resolved' AS DOUBLE PRECISION) = 1.0 "
"ORDER BY agent_runs.id LIMIT 200",
name=f"Sample 200 resolved runs by UUID",
)

DETECTOR_PROMPT = "..." # 簡略化のため省略
OUTPUT_SCHEMA = { ... } # 簡略化のため省略

detect = client.read(
prompt_template=[runs.run.as_type("agent_run"), DETECTOR_PROMPT],
model="openai/gpt-5.5",
reasoning_effort="medium",
output_schema=OUTPUT_SCHEMA,
name="Flag cheating from trajectory",
)

Claudeがこのスクリプトを実行すると、Docent SDKはすぐにリーディングを実行しません。代わりに、リクエストされたすべてのリーディングのグラフ（この場合は1つだけ）を構築し、分析計画としてDocentにアップロードします。これにより、LLM呼び出しの完了を待つ前に、提案された分析をレビューできます。

  1. 分析計画の構造

承認待ちの分析計画。

この分析計画は、エージェント実行メタデータをresolved=1にフィルタリングして成功した実行を選択するDQLクエリで始まります。その後、結果をリーディングステップに渡し、実行の不正行為をスコアリングします。

リーディングステップには以下のコンポーネントがあります：

  • パラメータ付きのプロンプトテンプレート。不正行為を検出するために、不審さを定義するルーブリックを作成し、1つのエージェント実行をパラメータとして取ります。Docent UIは完全なプロンプトテンプレートを表示し、パラメータはインラインで表現されます。下の「コンテキスト：実行」チップをクリックすると、LLMに渡される実行レベルのメタデータの詳細が表示されます。デフォルトではメタデータは渡されません。
  • 前のクエリステップからの引数。計画の前のクエリステップはresolved=1の実行のテーブルを生成しました。このテーブルの各行に対して、Docentはエージェント実行の全文をプロンプトテンプレートに代入し、LLMを呼び出します。
  • カスタム出力スキーマ。このリーディングは不審さを表す1から10の整数スコアと、引用を含む文字列の説明を出力します。DocentはLLMの出力がこのスキーマに準拠することを保証し、後のステップでデータ形式の問題が発生しないようにします。

リーディングは表現力豊かに設計されています。一般的なユースケースには、特定の行動についての実行の判断、以前のリーディング結果のクラスタリングによる高レベルのトレンド抽出、長いエージェント実行の要約、同じタスクの2つのロールアウトの比較などがあります。うまく機能するリーディングができたら、それをプリセットとして保存し、エージェントが後で再利用できるようにできます。

紫色のハイライトは、このリーディングがまだ承認を待っていることを示しています。承認しましょう。（Docent SDKはステップをプログラムで承認する方法も提供しています。コーディングエージェントに「分析計画を自動承認」と指示し、手動レビューをスキップできます。）

  1. リーディング結果のレビュー

不正スコアと推論、およびトランスクリプトの部分への引用を示すリーディング結果テーブル。

リーディング結果は検証のしやすさを考慮して設計されています。リーディングが実行されると、その結果がテーブルに表示されます。各行をクリックすると、新しいペインに完全な出力と、リーディングモデル、推論努力、使用トークンなどのメタデータが展開されます。

リーディング出力の主張には、トランスクリプトの特定の部分への引用が含まれています。青色の引用アイコンをクリックすると、トランスクリプトの関連部分にジャンプして主張を再確認できます。

  1. 結果の定量化

各スコアを受け取った実行の数と、そのカウントを生成するために使用されたクエリを上に表示。

全体像を把握するために、コーディングエージェントに、各不審スコアを受け取ったエージェント実行の数をカウントするDQLクエリを書くよう依頼できます。

最終結果の上の「クエリ」トグルをクリックすると、DQLクエリを一目で確認できます。正確なDQLを読むことで、誤ったグループ化、不適切なフィルタリング、間違った方法で計算された平均などのエラーをチェックできます。

  1. 不審な例の検証

報酬ハッキング判別器は誤検出で有名です。結果を新しいリーディングに渡し、フォローアップの質問をできます。

私たちのエージェントはDQLを使用して4つの不審な実行を抽出し、それぞれを検証するリーディングを作成します。検証リーディングは、ほとんどの不正事例が実際に不審であることを確認しますが、少なくとも1つは誤検出であることを示します。

Docentによってフラグ付けされた誤検出。

ある不審な実行には、前方参照による不正行為が含まれているように見えます。エージェントはgit履歴を調べ、別のコミットからコードを復元します。しかし、検証リーディングはこれを正しく誤検出として識別します。過去のコミットがリグレッションを導入したため、コードベースの元の状態を復元することは有効なパッチです。

さらなるケーススタディ

分析計画は、統一されたフレームワークを通じてさまざまなアプリケーションをサポートします。以下は、モデルの比較、障害モードの特定、予期しない行動の発見にどのように使用したかの例です。

▶