LangChain、評価ベンチ「IssueBench」発表

LangSmith Engine は、他のエージェントで発生する問題を検出し修正するために構築されました。これはバックグラウンドで動作し、エージェントのトレースを分析して問題を特定・クラスタリングし、最終的に解決策を提案します。

Engine の改良が進むにつれ、「変更を加えたことで、実際に問題発見能力が向上したのか」という単純な疑問に答える方法が必要になりました。

Engine を信頼できる形で評価するには、正解ラベル（ground-truth）を持つベンチマークが必要です。一部のトレースには既知の問題を含め、他のトレースはクリーンである必要があります。そして何より、これらのラベルの信頼性が担保されなければなりません。この課題を解決するために、私たちは内部ベンチマーク「IssueBench」を構築しました。

IssueBench が評価する内容

IssueBench は、Engine に求める業務のうち特定のターゲットに焦点を当てています。

合成された問題を混入させたトレースのバッチを与えられた際、Engine は以下のタスクを実行する必要があります：

• 問題の特定
• 失敗カテゴリの割り当て
• 既存の問題への関連付け
• 新しい失敗のグループ化

これがチームに提供される成果物です。この一連の問題リストは、生産環境のエージェント動作のデバッグ、テスト、修正を支援するために設計されています。

全体レベルでの評価が重要な理由は、トレース単位のラベルだけでは不十分だからです。Engine が 10 件の失敗トレースを検知しても、同じ根本原因に対して 10 個の別々の問題として報告されていれば、問題リストはノイズだらけになります。逆に、無関係な失敗を一つの広範な問題にまとめられてしまうと、問題を解決するために必要な詳細情報が失われます。また、実際の問題を検知してもカテゴリの割り当てが間違っていれば、担当者が誤ってルーティングされる可能性があります。

IssueBench は、Engine が生のトレースデータを有用なエンジニアリング作業に変換できるかを測定するものです。

IssueBench の仕組み

IssueBench は、15 のタスクから構成されています。各タスクには、エージェントの動作ログ（トレース）のバッチと、初期の問題リストが含まれています。トレースの中には正常なケースもあれば、既知でラベル付けされた失敗事例を含むものもあります。

各タスクでは、Engine がトレースデータと、過去に特定済みの問題に関する説明を受け取ります。Engine の役割は、トレースの中から問題を発見し、それらを既存の問題リストと論理的に関連づけることです。

これらのトレースと問題は、合成環境で生成されています。これにより、現実のエージェント実行に近い挙動を再現しつつも、評価の基準となる「正解（グランドトゥルース）」を厳密に制御することが可能になります。現在のテストスイートは、以下の 3 つのドメインを対象としています。

• SRE のログ分析
• ソフトウェアエンジニアリング
• カスタマーサポート

IssueBench は、これらドメイン全体で展開される 15 の問題カテゴリを網羅しています。異なる種類のエージェントに対して同じカテゴリの課題を課すことで、Engine が特定の分野に特有な表面的なパターンを単に暗記しているのではなく、根本的な失敗モードを理解できているかを検証できます。

IssueBench は Harbor 上で動作するため、各タスクはサンドボックス化されており、再現性が高く、隠された正解データに基づいてスコアリングされます。これにより、プロンプトやモデルの変更を比較検討しつつも、実際の運用環境で重視する挙動に近い状態で評価を行うことが可能になります。

失敗の分類体系

IssueBench は、Engine が分析対象とする失敗モードから抽出された固定されたカテゴリセットを使用します。ベンチマークが Engine のカテゴリ変更によっても一貫性を保てるよう、有効な問題リストは凍結（固定）されています。これらのカテゴリは、実際の運用チームが対応や修正を必要とする問題の種類に対応しています。

現在のカテゴリには以下が含まれます：

• PII 漏洩
• ハルシネーション（幻覚）
• システムプロンプトのドリフト
• 誤ったツールの使用
• 機能不足
• エラー回復の失敗
• ツール引数の誤り
• エージェントの無限ループ
• コンテキスト爆発
• ガードレールの迂回
• レスポンスの切り捨て
• ツールエラーの沈黙化（検出されないエラー）
• 計画の不備
• タスク回避
• 機能不足への認識欠如

失敗に明確なカテゴリを割り当てるのは重要です。なぜなら、それがその後の対応方針を決めるからです。ハルシネーション、検出されないツールエラー、機能不足はいずれもユーザー体験を損ないますが、それぞれが指向する修正策や責任を持つプロダクトオーナーは異なります。

有用な問題特定エージェントは、「何かおかしい」と気づくだけでなく、チームが対応・優先順位付け・後のテストに活用できる形で失敗を記述する必要があります。

新しい課題のグループ化: 新しい事象が、期待される新しいカードに適切にクラスタリングされているか。

このベンチマークは、課題の選別でよく見られる一般的な失敗モードに対して Engine の評価を行います。例えば、Engine が正しい痕跡を検知しながらも課題グループの更新を怠ったり、各 failing する痕跡ごとに個別のカードを作成したり、無関係な失敗を曖昧な一つのカードにまとめたり、既存の課題コンテキストを上書きしたりした場合は、評価から減点されます。

このスコアリングは、Engine に求めるべき振る舞いを反映しています。目的は単に疑わしい痕跡を指摘することだけではありません。チームが「何が失敗しているのか」を理解し、「次に何をすべきか」を判断できるような課題セットを生成することが真の目標です。

IssueBench の活用方法

私たちは内部で IssueBench を使用し、プロンプトやモデル、選別ロジックの変更に応じて Engine を評価しています。これにより、性能の低下（レグレスション）を検出し、曖昧な課題カテゴリをデバッグし、課題の特定がまだどこで破綻しているかを把握できます。

このベンチマークは、私たちが目指すプロダクトの振る舞いを明確にする際にも役立ちました。Engine が痕跡を誤分類した場合、その原因が必ずしもモデル自体の失敗とは限りません。時にはカテゴリの境界があいまいであったり、課題の説明が不十分であったり、チームが実際に問題を選別する際の基準とスコアリングルールが一致していなかったりするケースも含まれます。

このフィードバックループこそが、IssueBench を構築した主な理由です。これは「エージェントを改善するエージェント」を制御された環境で向上させるための手段を与えてくれます。

IssueBench構築から得た教訓

合成データは評価の較正に有効です。 実際のエージェントにモックされたツールや制約に対して行動させることで、現実的なトレースと信頼できるラベルというトレードオフにおいて最適なバランスを実現できました。

「問題なし」クラスも失敗事例と同様に重要です。 もしクリーンなトレースの中に隠れた問題を見過ごせば、偽陽性率が高まり、モデル間の比較が信頼できなくなります。

暗記ではなく理解をテストするため、異なるドメインで同じ失敗カテゴリを評価します。 どのモデルでも特定のエージェントの表面的なパターンを学習することは可能です。しかし、コーディング、SRE（サイトエンジニアリング）、サポートのエージェントにわたって幻覚（ハルシネーション）を検証することで、Engine がドメイン固有のアートファクトではなく、抽象的な失敗そのものを認識していることを示しています。これこそが、顧客が使用するあらゆるエージェントに対して Engine が重要な問題を見つけ出し、解決を支援できるという自信の根拠です。

今後の展望

IssueBench は現在、社内開発用のベンチマークとして運用されています。

このベンチマークには、現実的なトレースバッチと隠された正解データ、そしてイシューボードによる検証機能を備えた合成タスクが15件含まれています。今後はより多様なエージェントタイプへの対応、大規模なトレースバッチの追加、充実した初期状態のボード、そしてイシューカードの質をより細かく評価するスコアリング手法の拡充を予定しています。

このアプローチを共有するのは、チームがエージェントを実環境に導入するにつれ、こうした種類の評価がますます重要になっているからです。エージェントがトレースの検査や失敗の特定、修正提案を担当するようになれば、その業務自体にも適切なベンチマークが必要となります。

IssueBench は、そのワークフローを測定可能なものにするための手法です。これは、Engine が生産環境のトレースデータを具体的なアクションに結びつける能力を評価するものです。