LangChain、評価ベンチ「IssueBench」発表
LangChain は開発者が AI エンジンの性能を客観的に比較・検証するための新しいベンチマーク「IssueBench」を発表した。
キーポイント
評価ツールの新発表
LangChain が開発者向けに、AI エンジンの性能を客観的に比較・検証するための新しいベンチマークツール「IssueBench」を発表しました。
客観的な比較の実現
このツールは、主観的な評価ではなく、開発者が異なる AI エンジンのパフォーマンスを公平に測定し比較することを目的としています。
エンジニアリング品質の向上
AI アプリケーションの開発プロセスにおいて、エンジン選定や最適化のための標準的な検証手段を提供することで、全体の品質向上を図ります。
重要な引用
LangChain がエンジン評価のための新しいベンチマーク「IssueBench」を発表した
開発者が AI エンジンの性能を客観的に比較・検証するためのツールである
影響分析・編集コメントを表示
影響分析
この発表は、AI エンジンの評価基準が主観やベンチマークの欠如から脱却し、より構造化された客観的指標へと移行する重要な転換点です。開発者コミュニティにとっては、最適なエンジン選定やパフォーマンス最適化のための具体的な指針となり、結果として AI アプリケーションの信頼性と品質向上に寄与すると考えられます。
編集コメント
AI エンジンの性能評価において、開発者が公平に比較できる客観的指標の整備は極めて重要です。IssueBench の登場により、より質の高い AI アプリケーションの開発環境が整いつつあると言えます。
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 が生産環境のトレースデータを具体的なアクションに結びつける能力を評価するものです。
原文を表示
We built LangSmith Engine to find and fix issues in other agents. It runs in the background and looks at agent traces to try to identify, cluster, and then fix issues. As we improved Engine, we needed a way to answer a simple question: were our changes actually making it better at finding issues?
To evaluate Engine with confidence, we needed a benchmark with ground-truth labels. Some traces needed to contain known issues. Other traces needed to be clean. And we needed to trust both labels. We built an internal benchmark called IssueBench to solve that problem.
What IssueBench evaluates
IssueBench focuses on a targeted subset of the work we ask Engine to do.
Given a batch of traces with synthetically injected issues mixed in, Engine needs to:
- Identify issues
- Assign failure category
- Attach to existing issues
- Group new failures
This is the artifact Engine produces for teams: a set of issues that should help them debug, test, and fix production agent behavior.
Evals at the overall level are important because a trace-level label is not enough. If Engine flags ten failing traces but creates ten separate issues for the same root cause, the issue set becomes noisy. If it merges unrelated failures into one broad issue, the team loses the detail needed to fix the problem. If it detects a real issue but assigns the wrong category, it may get routed to the wrong owner.
IssueBench measures whether Engine can turn raw traces into useful engineering work.
How IssueBench works
IssueBench is composed of 15 tasks. Each task contains a batch of agent traces and a starting set of issues. Some traces are clean, while others contain known and labeled failures.
For each task, Engine receives the traces, along with descriptions of previously-known issues. It must find issues in the traces, then connect them back to known issues in a reasonable way.
The traces and issues are generated in synthetic environments. This gives us controlled ground truth while still producing traces that resemble real agent runs. The current suite covers three domains:
- SRE log analysis
- Software engineering
- Customer support
IssueBench spans 15 issue categories expressed across those domains. Running the same categories across different agent types helps test whether Engine has learned the underlying failure mode, rather than memorizing domain-specific surface patterns.
IssueBench runs on Harbor so each task is sandboxed, reproducible, and scored against hidden ground truth. That lets us compare prompt and model changes while keeping the evaluation close to the production behavior we care about.
The failure taxonomy
IssueBench uses a fixed set of issue categories pulled from the failure modes Engine analyzes against. It uses a frozen set of valid issues to ensure the benchmark stays consistent even if Engine changes its categories. These categories map to the kinds of problems production agent teams need to route and fix.
The current category set includes:
- PII leak
- Hallucination
- System prompt drift
- Wrong tool
- Feature gap
- Failed error recovery
- Incorrect tool args
- Agent looping
- Context explosion
- Guardrail bypass
- Response truncation
- Silent tool error
- Flawed plan
- Task evasion
- Missing capability awareness
Assigning clear categories to failures is important because it determines what happens next. A hallucination, a silent tool error, and a feature gap may all produce a bad user experience, but they usually point to different fixes and different product owners.
A useful issue-identification agent needs to do more than notice that something went wrong. It needs to describe the failure in a way the team can route, prioritize, and test against later.
How we score the output
IssueBench scores Engine results to ensure it’s finding and grouping issues in a useful way.
Classification: whether each trace is correctly labeled as an issue or no issue.
Issue category: whether failing traces receive the correct failure category.
Existing issue assignment: whether matching traces are attached to the right existing issue cards.
New issue grouping: whether novel failures are clustered into the expected new cards.
The benchmark docks Engine for common failure modes we see in issue triage. For example, Engine should lose credit if it detects the right traces but fails to update the issue groups, creates one card per failing trace, merges unrelated failures into one vague card, or overwrites existing issue context.
This scoring reflects the behavior we want from Engine. The goal is not just to flag suspicious traces. The goal is to produce a set of issues that helps a team understand what is failing and what work should happen next.
How we use IssueBench
We use IssueBench internally to evaluate Engine as we change prompts, models, and triage behavior. It helps us catch regressions, debug ambiguous issue categories, and understand where issue identification still breaks down.
The benchmark has also been useful for clarifying the product behavior we want. When Engine misclassifies a trace, the error is not always just a model failure. Sometimes it exposes an unclear category boundary, an underspecified issue description, or a scoring rule that does not match how a team would actually triage the problem.
That feedback loop is the main reason we built IssueBench. It gives us a controlled way to improve the agent that improves agents.
What We Learned From Building IssueBench
Synthetic data improves eval calibration. Using a real agent taking steps against mocked tools and constraints gave us the best tradeoff between realistic traces and labels we could trust.
The no-issue class is just as important as the failures. If “clean” traces hide issues, false positive rate gets noisy and model comparisons stop being trustworthy.
To test understanding, not memorization, we run the same failure categories across domains. Any model can learn a specific agent’s surface patterns. Testing for hallucination across the coding, SRE, and support agents shows Engine recognizes the abstract failure - not just domain-specific artifacts. That's what gives us confidence that whatever agent a customer runs, Engine can find the issues that matter and help fix them.
What comes next
IssueBench is currently an internal development benchmark.
It contains 15 synthetic tasks with realistic trace batches, hidden ground truth, and issue-board verification. We expect to expand it across more agent types, larger trace batches, richer starting boards, and more nuanced scoring of issue-card quality.
We’re sharing the approach because this class of evaluation is becoming more important as teams put agents into production. When agents are responsible for inspecting traces, identifying failures, and proposing fixes, teams need benchmarks for that work too.
IssueBench is our way of making that workflow measurable. It evaluates Engine’s ability to turn production traces into actionable issues.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み