Передовые модели тихо разрушают ваши документы в длинных рабочих процессах. Не случайно. Систематически.
Филипп Лабан (Salesforce Research), Тобиас Шнабель и Дженнифер Невилл опубликовали DELEGATE-52 на arXiv — масштабный бенчмарк по 52 профессиональным областям и 19 LLM. Выводы неутешительны: даже модели уровня Gemini 3.1 Pro, Claude 4.6 Opus и GPT 5.4 разрушают в среднем 25% содержимого документов к концу длинных рабочих процессов.
Что означает «разрушение»
«Разрушение» здесь не означает, что модель возвращает бессмысленный текст. Это означает, что после получения делегированной задачи (редактирование документа, изменение кода, обновление отчёта) модель вносит ошибки или удаляет корректное содержимое без соответствующей команды.
Редко, но смертельно.
DELEGATE-52 моделирует реальные делегированные рабочие процессы: вы даёте LLM документ, просите внести серию правок, затем проверяете результат. 52 области охватывают кодирование, кристаллографию, музыкальную нотацию и другие.
Результаты:
- Передовые модели (Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4): ~25% содержимого разрушено к концу длинных рабочих процессов
- Остальные модели: более высокие показатели отказов; некоторые модели становятся практически непригодными на поздних этапах
- Использование инструментов Agent не улучшает результаты: добавление возможностей вызова инструментов не улучшило показатели на DELEGATE-52
- Большие документы = больше разрушений: размер документа и длина взаимодействия положительно коррелируют с частотой ошибок
- Отвлекающие файлы усугубляют проблему: наличие нерелевантных файлов в рабочей директории повышает частоту ошибок модели
Корень проблемы
Объяснение в статье: текущие LLM — ненадёжные делегаты. Они вносят «редкие, но серьёзные ошибки», которые накапливаются в ходе длительных взаимодействий.
Это не проблема типа «переключись на лучшую модель». Протестированные модели уже сильнейшие из доступных. Корневая причина кроется в архитектуре LLM — они вероятностны, а не детерминированы. В коротких диалогах эта неопределённость приемлема. В длинных рабочих процессах каждый вызов — это бросок кубика. Брось достаточно раз, и что-то пойдёт не так.
Что ещё хуже: ошибки происходят незаметно. Модель не скажет вам «я изменила формулу в третьем абзаце». Она просто изменит и вернёт результат с полной уверенностью.
Что это значит для вас
Если вы используете LLM для редактирования документов, рефакторинга кода или обновления отчётов:
Короткие задачи — в порядке. Редактирование нескольких строк кода или adjustment абзаца — передовые модели справляются с этим надёжно.
Длинные рабочие процессы требуют человеческих контрольных точек. Позволить LLM непрерывно редактировать 50-страничный документ без промежуточных проверок — почти гарантированно получить нежелательные изменения.
Отвлекающие файлы — это ловушка. Смешивание нерелевантных файлов в рабочей директории повышает частоту ошибок. Чистота рабочего пространства — это не только вопрос стиля кода, но и вопрос безопасности.
Вызов инструментов — не панацея. Эта статья явно показывает, что добавление возможностей вызова инструментов не улучшает производительность делегированных задач. Не думайте, что оснащение Agent инструментами чтения/записи файлов автоматически решает проблему надёжности документов.
Моя оценка
Ценность этой статьи в том, что она использует масштабные данные, чтобы развеять иллюзию: «передовые модели достаточно надёжны, чтобы доверить им документы».
Реальность такова, что для делегированных задач, требующих точности, текущая лучшая практика остаётся «LLM генерирует + человек проверяет». Не потому что LLM слабы — а потому что их вероятностная природа делает их непригодными для работы, требующей 100% определённости.
Значение DELEGATE-52 не в том, чтобы сказать нам, что LLM плохи. Он предоставляет количественную базовую линию. 25% разрушения — это отправная точка, а не конечная. Когда выйдет следующая модель, мы сможем использовать тот же бенчмарк для отслеживания прогресса.
А до тех пор не отдавайте важные документы LLM и не уходите.
Основные источники:
- LLMs Corrupt Your Documents When You Delegate, Philippe Laban et al., arXiv:2604.15597
- Обсуждение на Hacker News