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 将生产轨迹转化为可行动问题的能力。