AI行為可驗證分析框架

開發AI代理是一個複雜的數據分析問題。要判斷代理是否正常工作，不僅需要跟蹤基準分數，還需要了解其行為的細節：策略在訓練過程中如何變化？為什麼新的腳手架表現更差？是否存在獎勵黑客？回答這些問題需要結合定量和定性分析，並針對手頭的數據集進行定製。

編碼代理有潛力加速這項工作，但它們容易犯細微的錯誤：可能錯誤解析數據、做出無根據的假設，或者挑選例子並呈現誤導性敍述。這些錯誤在最終輸出中並不明顯。要信任結論，我們需要驗證其產生過程。但審查編碼代理採取的所有行動很繁瑣——關鍵的方法決策被埋藏在數百行日誌中。

這一問題促使我們開發了分析計劃，這是一個用於可驗證AI行為分析的框架。分析計劃通過Python API指定，任何編碼代理都可以使用。當它們準備運行時，會顯示在Web界面中，讓人類理解和驗證所採取的每個步驟。

分析計劃包含兩種步驟：

• 查詢步驟使用DQL（Docent的SQL子集）過濾、分組和連接數據。每個步驟顯示其查詢和結果的交互式表格。
• 閲讀步驟使用LLM分析來自查詢步驟的數據，生成文本摘要和/或結構化判斷。LLM提出的聲明附有對上下文中特定項目的引用。

這兩種步驟可以定製和組合，構建複雜的分析管道。閲讀可以接受查詢產生的任何數據，查詢也可以在閲讀結果上運行。每一步的結果都追溯到產生它的確切計算，便於檢查、審計和優化流程。

讓我們通過檢測一個流行的軟件工程基準上的作弊行為來看看它的實際應用。

演示：識別SWE-rebench中的可疑行為

作弊是解釋評估結果時常見的痛點：模型常常硬編碼測試、虛假聲稱成功，並利用不乾淨的環境複製解決方案。衡量作弊率對於理解基準分數在多大程度上代表模型能力的有效展示至關重要。我們在大約15分鐘內使用Docent發現了SWE-rebench上的作弊實例，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不會立即執行閲讀。相反，它會構建所有請求閲讀的圖形（本例中僅一個）並將其作為分析計劃上傳到Docent。這讓我們可以在等待LLM調用完成之前審查提議的分析。

1. 分析計劃的剖析

一個等待批准的分析計劃。

該分析計劃以一個DQL查詢開始，通過過濾代理運行元數據為resolved=1來選擇成功的運行。之後，它將結果傳遞給一個閲讀步驟，對運行進行作弊評分。

一個閲讀步驟包含以下組件：

• 帶有參數的提示模板。為了檢測作弊，我們創建一個定義可疑度的評判標準，將一個代理運行作為參數。Docent UI顯示完整的提示模板，參數內聯表示。點擊下面的“上下文：運行”芯片會暴露更多關於傳遞給LLM的運行級元數據的細節。默認情況下，不傳遞元數據。

• 來自先前查詢步驟的參數。我們計劃中的上一個查詢步驟產生了一個resolved=1的運行表。對於該表中的每一行，Docent會將代理運行的完整文本替換到提示模板中，並調用LLM處理。

• 自定義輸出模式。該閲讀輸出一個從1到10的整數分數表示可疑度，以及一個包含引用的字符串解釋。Docent確保LLM輸出符合此模式，以便後續步驟不會遇到數據格式問題。

閲讀被設計為富有表現力。常見用例包括判斷特定行為的運行、聚類先前閲讀的結果以提取高層次趨勢、總結長代理運行，或比較同一任務的兩次展開。一旦您有了一個運行良好的閲讀，您可以將其保存為預設，以便代理以後重用。

紫色高亮表示該閲讀正在等待我們的批准，所以讓我們批准它。（Docent SDK也提供了一種以編程方式批准步驟的方法；您可以告訴您的編碼代理“自動接受分析計劃”並跳過手動審查。）

1. 審查閲讀結果

閲讀結果表顯示作弊分數和推理，以及鏈接到轉錄部分的引用。

閲讀結果設計為便於驗證。當閲讀執行時，其結果會出現在一個表中。點擊每一行會在新窗格中展開結果，顯示完整輸出和元數據，如閲讀模型、推理努力和使用的令牌。

閲讀輸出中的聲明包括對轉錄特定部分的引用。點擊藍色引用圖標可跳轉到轉錄的相關部分並再次檢查聲明。

1. 量化結果

每個分數對應的運行數量，以及用於生成計數的查詢顯示在上方。

為了獲得總體情況，我們可以讓我們的編碼代理編寫一個DQL查詢，計算每個可疑度分數對應的代理運行數量。

我們可以通過點擊最終結果上方的“查詢”切換來一目瞭然地驗證DQL查詢。閲讀精確的DQL可以讓您檢查錯誤，例如不正確的分組、不正確的過濾，或使用錯誤方法計算的平均值。

1. 驗證可疑示例

獎勵黑客評判器以虛假陽性聞名。我們可以將結果傳遞給一個新的閲讀並提出後續問題。

我們的代理使用DQL提取四個可疑的運行，並創建一個閲讀來驗證每一個。驗證器閲讀確認大多數作弊示例實際上是可疑的，但至少有一個是誤報。

Docent標記的一個誤報。

一個可疑運行似乎包含通過前向查看的作弊：代理檢查git歷史並從另一個提交恢復代碼。但驗證器正確地將此識別為誤報：過去的提交引入了迴歸，因此恢復代碼庫的原始狀態是一個有效的補丁。

更多案例研究

分析計劃通過一個統一框架支持各種應用。以下是我們如何使用它們來比較模型、識別故障模式和發現意外行為的示例。

▶