Аптайм 97–100% за весь день. Количество готовых результатов — ноль. Оба числа верные. Так выглядел один из дней в компании, которая два месяца гоняла 78 LLM-агентов без человека между расписанием и результатом, и честно записывала каждый сбой.

Команда GXCafe выложила в открытый доступ датасет из 6768 записей об отказах, собранных за 58 дней реальной эксплуатации агентного бэк-офиса: бухгалтерия, разбор почты, драфтинг, ревью, ресёрч. Локальные модели 7B–35B, задачи в основном на японском, никакого человека в контуре. Это редкий документ: не бенчмарк и не демка, а полевой журнал того, что на самом деле ломается, когда агенты работают unattended.

Почему дашборды врут, даже когда не врут

Каждый из 6768 зафиксированных отказов вернул HTTP 200. Каждый выдал текст правдоподобной длины со связной прозой. Каждый был записан мониторингом как успешное завершение. Если ваш дашборд говорит, что агент отработал, всё что вы узнали — это что агент отработал.

Это центральная неприятность всей истории. Инфраструктурный мониторинг измеряет вызовы, а не результаты, и разрыв между этими двумя вещами может расти неделями, не вызывая ни одного алерта. У GXCafe 78 агентов когда-то были полностью исключены из программы исправления ошибок, потому что планировщик каждый час трогал их лог запуска — метрика «агент недавно стартовал» была зелёной у всех. Число было настоящим. Оно измеряло не то.

43% отказов — это скучно

Когда записи разложили по типам, картина оказалась неожиданной для любого, кто читает новости об ИИ-безопасности. Из 15251 пометок типа (один отказ может нести несколько) самые частые категории: 4875 прочих мелких нарушений, 4054 слишком коротких ответов (включая ноль символов при минимуме в 150), 2535 пропущенных обязательных элементов, 2330 запрещённых фраз в тексте.

Итого 6589 пометок — 43% — это банальные нарушения формы. Не галлюцинации. Не джейлбрейки. Не безопасность. Модель ответила, но в неправильной форме: пропустила заголовок, на который завязан downstream-парсер, выдала ноль символов, написала не на том языке.

А драматичные сбои, под которые индустрия пишет evals, — отказы отвечать (36 случаев) и ответы на чужой вопрос (220) — оказались самыми редкими вещами в датасете. Вместе они дают 1,7%. Команда честно признаёт: их собственный контур ревью был построен именно вокруг драматичных случаев.

Самый дорогой сбой — пропущенная строка

Крупнейший единичный тип нарушений, 2535 случаев, — одна пропущенная строка: 判定:. Слово означает «вердикт». Контракт агента-ревьюера требует, чтобы строка начиналась с этого слова, потому что следующая стадия пайплайна читает именно её и решает, пропускать ли материал дальше. Модель писала вдумчивое, правильное, хорошо структурированное ревью — и помещала вердикт внутри прозы, а не на строке с нужным префиксом.

Ревью отличное. Ревьюер не ошибся. Следующая стадия не может прочитать ответ.

В этом суть дороговизны форматных сбоев: они невидимы при ручной выборочной проверке. Человек читает текст, видит хорошее ревью и делает вывод, что агент работает. А пайплайн тем временем молча стоит.

Отдельная находка, которой даже нет в датасете: 42 элемента были одобрены верхней стадией и не породили никакой работы ниже. Причина оказалась не в модели вовсе — downstream-стадия генерировала свой вход из четырёх захардкоженных предложений и вообще никогда не читала выход верхней. Так было с самого начала. Обе стадии неделями рапортовали об успехе. Теперь на каждом артефакте записывают, из какого артефакта он произведён, чтобы непрочитанный выход был виден как число, а не как отсутствие.

Языковая деградация невидима, если вы читаете только английский

Третий по величине кластер — 1048 пометок — это языковые сбои: ответы не на японском (172), китайские иероглифы в японском тексте (243), бессмысленная смесь японского с английскими служебными словами (609), утечки английских рассуждений в итоговый текст (24).

Один пример стоит прочитать дважды. Во время тестирования кандидатской модели — с теми же контрактами, что в проде — модель выдала 1680 символов уверенного, хорошо отформатированного текста для японского ревью, в котором не было ни одного знака каны. Текст был целиком китайским. Длина — пройдена. Структура — пройдена. Проверяющий, не знающий японского, увидел бы завершённую задачу.

Если вы работаете не на английском, язык обучающих данных базовой модели будет просачиваться, и просачиваться так, что пройдёт все ваши структурные проверки. У GXCafe теперь наличие каны — жёсткий гейт, а модель-писатель и модель-ревьюер всегда из разных семейств, чтобы общесемейный языковой сбой не мог одобрить сам себя. Это не теория: когда они кратко использовали одно семейство для обеих ролей, ревьюер одобрил шесть подряд ответов на неправильном языке.

Четыре изменения, которые реально сработали

Первое и главное: форма ответа объявляется явно и проверяется машиной до того, как её прочитает что-либо downstream. Минимальная длина, обязательные паттерны, запрещённые паттерны, ожидаемый язык, а для всего с числами — пометка, измерено число, поставлено как цель, предположено или оценено. Из этой работы родился опубликованный инструмент honto-contract — без зависимостей, синхронный, работает с любой строкой. Он существует, потому что был нужен, а не наоборот.

Второе: при сбое записывать почему, а не что. Первые 41 день команда писала «контракт не выполнен» и выбрасывала причины. 1381 из 6768 записей не несут причины, и восстановить их невозможно — выходы удалены. На заметку об этом ушло три недели, потому что «ноль сбоев с причиной» и «ноль сбоев» выглядят на графике одинаково. Эти 1381 строк остались в датасете с пометкой, потому что удалить их значило бы исказить то, что известно.

Третье: не позволять писателю одобрять собственную работу. Ревьюер не делит семейство с писателем.

Четвёртое: измерять произведённый результат, а не вызовы. Недели ушли на то, чтобы судить «работает ли агент» по тому, запускался ли он недавно.

Почему индустрия смотрит не туда

Распределение GXCafe объясняет странный разрыв между тем, что обсуждают на конференциях, и тем, что болит в продакшене. Публичная повестка агентной безопасности крутится вокруг джейлбрейков, prompt injection и моделей, отказывающихся выполнять вредоносные запросы. Это реальные проблемы, но в 58-дневном журнале реальной эксплуатации их доля измеряется единицами процентов. Основная масса потерь — тихая: пайплайн зелёный, артефактов ноль, и никто не знает, в какой момент это началось.

Причина разрыва проста. Драматичные сбои видны человеку без инструментов: модель выдала чушь, отказалась отвечать, написала что-то неуместное — это заметно на скриншоте. Форматный сбой виден только машине, которая знает контракт. Если контракт нигде не объявлен явно, сбой не существует ни в одной системе учёта. Получается выборка, искажённая наблюдаемостью: мы тестируем то, что легко заметить, а не то, что чаще ломается.

Как выглядит минимальный контракт

Идея honto-contract сводится к нескольким строкам проверок, выполняемых синхронно сразу после генерации. Для агента-ревьюера из истории выше контракт включал бы минимальную длину, обязательный паттерн строки вердикта, запрещённые фразы, проверку языка по наличию каны, а для чисел — требование пометить каждое как измеренное, целевое, предположенное или оценённое. Проверка дешёвая, детерминированная и не зависит от второй модели.

Важен порядок: контракт проверяется до того, как результат уйдёт downstream. Отказ на этом этапе стоит один перезапуск генерации. Тот же отказ, обнаруженный через неделю в виде отсутствующих артефактов, стоит расследования всего пайплайна. В терминах датасета: 2535 случаев пропущенного вердикта — это 2535 дешёвых перезапусков или одна очень дорогая неделя тишины, смотря где вы их ловите.

Что это значит для ваших агентов

Если вы строите агентные пайплайны, этот датасет меняет приоритеты тестирования. Evals, которые проверяют отказы отвечать, джейлбрейки и галлюцинации, покрывают 1,7% реального распределения отказов. Остальное — контракты формата, языковые гейты и проверка того, что выход одной стадии действительно читается следующей.

Практический минимум, который стоит внедрить до запуска: машинная проверка формы каждого ответа до downstream, логирование причин сбоев с первого дня, разнесение писателя и ревьюера по разным модельным семействам, метрика «произведённые артефакты» вместо «успешные запуски». Ничто из этого не требует новых моделей — только честности о том, что именно вы измеряете.

Стоит держать в голове и границы данных. Это записи одной организации: 58 дней, локальные модели 7B–35B, преимущественно японские задачи. Датасет не скажет, что сломается у вас. Он показывает, какого рода вещи ломаются, когда никто не смотрит, — и это та часть, которую команда сама не смогла нигде найти, когда она была нужна. Журнал продолжает пополняться: система работает до сих пор, и новые отказы публикуются по мере накопления. Авторы прямо предлагают писать им, если вы считаете данные ошибочными, — редкий уровень открытости для материала, который легко можно было бы выдать за рекламный кейс.

Часто задаваемые вопросы

Чем форматные сбои опаснее галлюцинаций?

Галлюцинацию замечает человек при выборочной проверке, потому что текст выглядит подозрительно. Форматный сбой выглядит как отличный ответ: проблему видит только следующая стадия пайплайна, которая не может распарсить результат и молча останавливается. У GXCafe 43% всех отказов — именно такие.

Зачем писателю и ревьюеру быть из разных семейств моделей?

У моделей одного семейства общие слепые зоны: общий языковой уклон, общие привычки форматирования. Когда GXCafe использовала одно семейство для обеих ролей, ревьюер одобрил шесть подряд ответов не на том языке. Разные семейства не гарантируют независимости, но убирают систематические общие отказы.

Подойдёт ли этот датасет как бенчмарк для моей системы?

Нет, и авторы подчёркивают это сами. Это журнал одного продакшена, а не бенчмарк: одна организация, один языковой профиль, маленькие локальные модели. Ценность в таксономии отказов, а не в числах для сравнения.

Итог

Главный урок 58 дней unattended-агентов: системы ломаются не там, где их проверяют. Драматичные сбои, о которых пишут статьи и под которые строят evals, — 1,7% реальных отказов. Остальное — скучная, дорогая, невидимая для дашбордов механика: пропущенная строка, непрочитанный выход, китайский текст вместо японского при пройденных проверках длины и структуры. Возьмите датасет GXCafe, сопоставьте таксономию со своим пайплайном и проверьте: ваши метрики измеряют запуски или результаты?