IssueBench – 如何評估引擎

LangChain 構建了 LangSmith Engine 來發現並修復其他代理中的問題。Engine 在後臺執行，分析代理軌跡以識別、聚類並修復問題。為了在改進 Engine 時能可靠地判斷變更是否有效，團隊需要一個帶有真實標籤的基準測試。於是他們開發了內部基準 IssueBench。

IssueBench 專注於 Engine 需要完成的一部分任務：給定一批混入合成問題的軌跡，Engine 需要識別問題、指定失敗類別、關聯到現有問題以及分組新故障。最終產出是一組有助於團隊除錯、測試和修復生產代理行為的問題。

整體層面的評估至關重要，因為僅靠軌跡層面的標籤不夠。如果 Engine 標記了十條失敗軌跡，但為同一根因建立了十個獨立的問題，問題集合就會變得嘈雜；如果它將無關的失敗合併為一個寬泛的問題，團隊就會失去修復所需的細節。IssueBench 衡量 Engine 能否將原始軌跡轉化為有用的工程工作。

IssueBench 由 15 個任務組成，每個任務包含一批代理軌跡和一組起始問題。部分軌跡是乾淨的，另一些包含已知和標記的失敗。Engine 接收軌跡和先前已知問題的描述，必須在軌跡中找到問題並以合理的方式關聯回已知問題。軌跡和問題在合成環境中生成，從而在保持真實性的同時提供可控的真相。

基準覆蓋三個領域：SRE 日誌分析、軟體工程和客戶支援，共包含 15 個問題類別。跨域執行相同類別有助於測試 Engine 是否學到了底層失效模式，而非記憶特定領域的表面模式。

IssueBench 在 Harbor 上執行，每個任務都被沙盒化、可復現，並根據隱藏真相進行評分。這使得團隊可以比較提示和模型更改，同時使評估貼近關心的生產行為。

IssueBench 使用一組固定的問題類別，包括 PII 洩露、幻覺、系統提示漂移、工具錯誤、特性缺失、錯誤恢復失敗、工具引數不正確、代理迴圈、上下文爆炸、防護欄繞過、響應截斷、靜默工具錯誤、計劃缺陷、任務規避和缺少能力意識。清晰的類別分配決定了後續處理方式：不同的失敗通常指向不同的修復方案和產品負責人。

評分方式確保 Engine 以有用的方式發現和分組問題。具體包括：每條軌跡是否正確標記為問題或無問題；失敗軌跡是否獲得正確的失敗類別；匹配的軌跡是否附加到正確的現有問題卡；新的失敗是否聚類到預期的新卡片。基準會扣除常見失敗模式的分數，例如檢測到正確軌跡但未更新問題組、為每條失敗軌跡建立單獨卡片、將無關失敗合併成模糊卡片或覆蓋現有問題上下文。

LangChain 內部使用 IssueBench 評估 Engine 在提示、模型和分類行為變化時的表現，幫助捕捉迴歸、除錯模糊的問題類別，並瞭解問題識別在哪些環節仍存在問題。基準還有助於明確產品行為——當 Engine 錯誤分類時，錯誤有時不僅是模型失敗，還可能暴露了不清晰的類別邊界、不充分的描述或與團隊實際分類方式不匹配的評分規則。

構建 IssueBench 的經驗包括：合成資料改善了評估校準；使用真實代理在模擬工具和約束下執行步驟，在真實軌跡和可信標籤之間取得了最佳平衡；“無問題”類別與失敗類別同等重要；為了測試理解而非記憶，在多個領域執行相同的失敗類別，確保 Engine 識別的是抽象失敗而非特定領域的表象。

IssueBench 目前是一個內部開發基準，包含 15 個合成任務，具有真實的軌跡批次、隱藏真相和問題板驗證。團隊計劃將其擴充套件到更多代理型別、更大的軌跡批次、更豐富的起始板以及更精細的問題卡質量評分。分享這種方法是因為隨著團隊將代理投入生產，這類評估變得越來越重要。IssueBench 是使工作流可測量的方式，它評估 Engine 將生產軌跡轉化為可行動問題的能力。