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歷史並從另一個提交恢復程式碼。但驗證器正確地將此識別為誤報：過去的提交引入了迴歸，因此恢復程式碼庫的原始狀態是一個有效的補丁。

更多案例研究

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

▶