LangChain представила IssueBench - синтетический бенчмарк для оценки агента-диагноста LangSmith Engine. Бенчмарк проверяет, насколько точно Engine находит и классифицирует проблемы в трассировках других агентов. Цель - превратить работу с инцидентами в продакшен-агентах в измеримую, воспроизводимую метрику.
Сложность AI-агентов растёт, цепочки вызовов удлиняются, а отказы становятся каскадными. Ручной разбор логов уже не справляется с объёмом - нужен автоматический диагност. IssueBench даёт эталонные метки для оценки такого диагноста: 15 задач в трёх предметных областях, четыре критерия оценки, синтетические трассировки с известным ground truth.
Пока бенчмарк используется внутри LangChain, но команда планирует расширение. Разберём, как он устроен и почему синтетические данные - осознанный выбор, а не компромисс.
Что такое IssueBench и зачем он нужен
IssueBench - синтетический бенчмарк, созданный для оценки LangSmith Engine, агента-диагноста, который анализирует трассировки других агентов и выявляет в них проблемы. Бенчмарк не тестирует способность агента выполнять задачи пользователя - он проверяет, насколько хорошо агент понимает, что пошло не так у другого агента.
Потребность в таком инструменте назрела. Продакшен-агенты генерируют тысячи трассировок в час. Одна ошибка валидации на входе может породить десятки вторичных сбоев ниже по цепочке. Инженеру нужно быстро понять: это новый инцидент или уже известный? Критический или можно отложить? IssueBench формализует эти вопросы в измеримые критерии.
LangChain уже развивает направление автоматического тестирования агентов. Например, Eval Engineering Skill сканирует репозиторий и трейсы, генерируя контейнеризированные тесты. IssueBench дополняет этот подход: если Eval Engineering проверяет корректность поведения агента, то IssueBench оценивает качество диагностики, когда поведение уже отклоняется от нормы.
Четыре критерия оценки: как IssueBench тестирует агента-диагноста
Бенчмарк оценивает LangSmith Engine по четырём критериям. Каждый покрывает отдельный этап работы с инцидентом - от обнаружения до группировки. Эталонные метки для всех задач известны заранее, поэтому результаты можно сравнивать напрямую, без экспертной разметки.
Выявление проблем: полнота обнаружения сбоев
Первый критерий - recall в чистом виде. Агент получает трассировку, содержащую несколько проблем, и должен найти их все. Пропущенный сбой на этом этапе означает, что дальше его уже никто не увидит - ни автоматика, ни дежурный инженер.
Пример задачи из домена SRE: трассировка сервиса содержит всплеск 503-ошибок после деплоя новой версии. Агент должен зафиксировать сам факт аномалии, не отвлекаясь на фоновый шум из повторяющихся предупреждений о деплеции пула соединений, которые наблюдались и до инцидента. Эталонная метка: три проблемы в трассировке, агент должен обнаружить минимум две для прохождения теста.
Категоризация и привязка к инцидентам: точность диагностики
Найти проблему - половина дела. Дальше агент должен правильно определить тип сбоя и связать его с существующим инцидентом, если такой уже зарегистрирован. Здесь измеряется precision: агент не должен плодить дубликаты инцидентов, но обязан отличить новый тип отказа от вариации известного.
Задача из области разработки ПО: CI/CD пайплайн упал на стадии интеграционных тестов. Трассировка показывает таймаут при обращении к тестовой базе данных. Агент должен классифицировать это как «инфраструктурный сбой в тестовом окружении», а не «ошибку в коде», и привязать к уже открытому инциденту о деградации тестового кластера. Ошибка категоризации здесь уведёт разработчиков на ложный след - они пойдут переписывать тесты вместо того, чтобы подождать восстановления базы.
Группировка новых сбоев: умение обобщать
Четвёртый критерий проверяет способность агента кластеризовать проблемы, для которых ещё нет открытых инцидентов. Продакшен-система может генерировать сотни алертов об одном и том же сбое с разных нод - агент должен понять, что это один инцидент, а не сотня разных.
Пример из поддержки клиентов: пользователи массово жалуются, что не могут добавить товар в корзину. Сообщения различаются формулировками, браузерами и временем отправки, но корневая причина одна - отказ сервиса инвентаризации. Агент должен сгруппировать эти обращения в один инцидент, даже если в тексте тикетов ни разу не упоминается «сервис инвентаризации». Эталонная метка: один кластер, а не россыпь индивидуальных алертов.
Структура бенчмарка: 15 задач в трёх предметных областях
IssueBench состоит из 15 задач, равномерно распределённых по трём доменам. Выбор областей не случаен: SRE, разработка ПО и поддержка клиентов покрывают основные сценарии, в которых агенты уже работают в продакшене. Разные домены - разные паттерны отказов, разная структура логов, разная семантика ошибок.
SRE: анализ логов и инфраструктурных сбоев
Задачи этого домена построены вокруг типичных инфраструктурных инцидентов. Агенту нужно обнаруживать всплески ошибок в логах, находить корреляции между метриками и выявлять первопричину деградации сервиса. Трассировки имитируют реальные цепочки вызовов: gateway → service A → service B → database, с реалистичными таймингами и кодами ответов.
Одна из задач: service A начинает отвечать с задержкой 2+ секунды. Трассировка показывает, что проблема не в самом сервисе, а в service B, который медленно отвечает на запросы аутентификации. Агент должен указать первопричину - деградацию service B, а не симптом - медленный ответ service A.
Разработка ПО: ошибки в коде и пайплайнах
Домен покрывает сценарии из жизни разработчиков: падения сборок, регрессии, исключения в трейсах приложений. Трассировки здесь содержат стектрейсы, коды ошибок компиляции, результаты тестовых прогонов.
Характерная задача: ночной билд упал, но не на коде разработчиков, а на обновлении зависимости, которое принесло breaking change в минорной версии. Агент должен вычленить из логов сборки конкретную зависимость и версию, классифицировать сбой как «внешняя зависимость», а не «ошибка сборки», и предложить привязать инцидент к задаче на откат версии.
Поддержка клиентов: обработка обращений и инцидентов
Третий домен имитирует поток пользовательских обращений. Задачи включают категоризацию тикетов, выявление массовых проблем и привязку жалоб к известным багам. Трассировки здесь - это не системные логи, а цепочки обращений: пользователь → саппорт → эскалация → разработка.
Пример: десятки пользователей сообщают о списании средств без подтверждения заказа. Агент должен определить, что все обращения связаны с одним и тем же багом в платёжном шлюзе, и привязать их к существующему инциденту, даже если пользователи описывают проблему по-разному: «деньги списались, заказа нет», «двойное списание», «платёж прошёл, но статус не обновился».
Почему синтетические данные: эталонные метки и защита от переобучения
Выбор синтетических данных - ключевое архитектурное решение IssueBench. Реальные продакшен-трассировки имеют фундаментальную проблему: для них нет точного ground truth. Эксперт может разметить инциденты, но всегда останется субъективность - один инженер посчитает проблему критической, другой отложит её до утра. Синтетика даёт однозначные эталонные метки: авторы бенчмарка сами закладывают проблемы в трассировку и точно знают, сколько их, какого они типа и как должны быть сгруппированы.
Второй аргумент - контроль над распределением сценариев. В реальных логах за месяц может не случиться ни одного инцидента с каскадным отказом, а потом произойти сразу три за день. Синтетический бенчмарк гарантирует, что все типы проблем представлены в нужных пропорциях, и тестирование воспроизводимо.
Кросс-доменное тестирование: почему агент не должен запоминать паттерны
Синтетическая природа данных открывает ещё одну возможность - кросс-доменное тестирование. Агент может обучаться на трассировках из одного домена, а тестироваться на другом. Это принципиально важно для предотвращения переобучения на поверхностных паттернах.
Допустим, агент научился находить проблемы в логах SRE, запомнив, что слово «timeout» в стектрейсе всегда означает проблему. В домене поддержки клиентов слово «timeout» может встречаться в совсем другом контексте - пользователь жалуется, что «вышел по таймауту из аккаунта». Агент, переобучившийся на SRE-паттернах, ложно пометит это как инфраструктурный сбой. Кросс-доменное тестирование в IssueBench выявляет такие проблемы обобщения.
Сравнение с тестированием на реальных данных: реальные трассировки лучше отражают хаос продакшена - нестандартные форматы логов, частичную потерю данных, legacy-компоненты без структурированного логирования. Синтетика пока не воспроизводит этот уровень энтропии. Но для оценки диагностической логики агента она подходит лучше, потому что изолирует проверяемый навык от шума среды.
IssueBench в контексте Eval Engineering: как это меняет тестирование агентов
IssueBench не существует в вакууме - он часть более широкого движения к измеримому качеству AI-агентов. LangChain последовательно выстраивает экосистему: LangSmith для трейсинга, Eval Engineering для генерации тестов, IssueBench для оценки диагностики. Вместе они покрывают полный цикл: написал агента → запустил в тестовом контуре → собрал трассировки → автоматически проверил поведение → оценил способность диагностировать собственные сбои.
Отдельный интерес представляет связка с опытом Apollo, где шестиуровневая система LangSmith контролирует качество GTM-агентов. Там метрики используются для предотвращения деградации в продакшене. IssueBench добавляет к этому ещё один слой - автоматическую диагностику, когда деградация всё же произошла.
Среди других подходов к оценке агентов выделяются три направления. Статический анализ кода проверяет корректность промптов и цепочек вызовов до запуска, но не видит рантайм-поведения. Юнит-тесты для промптов проверяют конкретные сценарии, но требуют ручного написания. Трейсинг даёт полную картину исполнения, но не даёт эталонных меток. IssueBench занимает нишу между ними: он автоматизирован, как статический анализ, работает с рантайм-данными, как трейсинг, и даёт эталонные метки, как юнит-тесты.
Интересно сопоставить IssueBench с подходом Databricks к оценке агентов для кодинга. Их исследование показало, что открытая модель Z.ai GLM 5.2 не уступает проприетарным при затратах в 4 раза ниже, но ключевой инсайт там - важность правильного harness-тестирования. IssueBench решает сходную проблему для диагностики: важно не только качество модели-диагноста, но и корректность эталонных меток, против которых она оценивается.
Ограничения и планы развития
IssueBench - внутренний инструмент LangChain. Публичного доступа к бенчмарку нет, API для загрузки своих трассировок не предоставляется. Команда использует его для оценки и доработки LangSmith Engine, и прямых обязательств по открытию бенчмарка пока не давала. В планах - расширение набора задач, добавление новых предметных областей и возможный публичный доступ в будущем.
Синтетические данные, при всех преимуществах, имеют ограничения. Они не воспроизводят хаос реальных продакшен-систем: частичную потерю логов при сбоях, нестандартные форматы от legacy-компонентов, гонки состояний в распределённых системах. Агент, отлично прошедший IssueBench, может столкнуться с реальностью, где трассировка оборвана посередине, а часть спанов содержит бинарные данные вместо структурированного JSON.
Ещё одно ограничение: бенчмарк оценивает только диагностику, а не полный цикл работы с инцидентами. За кадром остаются приоритизация, автоматическое исправление, коммуникация с командой, постмортемы. Диагностика - критически важный, но не единственный компонент incident management.
Для тех, кто строит агентов на базе легковесных моделей, опыт сжатия BTL-3 Compact до 8.39 ГБ без потери агентной функциональности показывает, что диагностические способности можно сохранить даже при агрессивной квантизации. Это открывает путь к локальному запуску агентов-диагностов на одной карте, без зависимости от облачных API.
Выводы: что IssueBench значит для разработчиков агентов
IssueBench задаёт стандарт измеримости для агентов-диагностов. Четыре критерия - выявление, категоризация, привязка и группировка - можно использовать как чеклист для внутренней оценки собственных систем уже сейчас, не дожидаясь публичного доступа к бенчмарку.
Синтетические бенчмарки с кросс-доменным тестированием - перспективный подход, который решает проблему отсутствия эталонных меток в реальных данных. Если вы строите агента, который должен понимать, что пошло не так у другого агента, стоит закладывать в тестовый набор синтетические трассировки с известным ground truth.
LangChain продолжает инвестировать в измеримость агентных систем. IssueBench, Eval Engineering и LangSmith вместе формируют инфраструктуру, где качество агентов перестаёт быть предметом веры и становится предметом измерения. Для индустрии, которая движется к продакшен-агентам, это принципиальный сдвиг.