Учёные в Microsoft выяснили, что LLM портят документы! И что, мою апелляционную жалобу тоже?..

«25% содержимого документа искажено к концу взаимодействия» — Microsoft Research выкатил препринт со звучным заголовком «LLMs Corrupt Your Documents When You Delegate». Страшно, очень страшно, тон заголовка для академической статьи едва ли не скандальный, и очень легко использовать этот заголовок и абстракт, чтобы поставить клеймо, что не нужны они нам эти ваши нейросети.

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

Методика исследования

Команда Microsoft Research собрала бенчмарк DELEGATE-52 — 52 профессиональных домена со структурированными документами. Туда вошли бухгалтерские журналы, ноты, описания тканей, 3D-модели, конфиги DNS-зон, расписания транспорта, шахматные партии, Python-код и много ещё чего. В каждом домене — настоящие документы стандартизированного формата и подобранный для них воркфлоу: 5–10 пар обратимых правок и «отвлекающий контекст» из тематически близких файлов.

Главный механизм эксперимента — backtranslation. Для каждой правки авторы придумывали обратную, отменяющую её. Например, «раздели бухгалтерский журнал на файлы по категориям» → «слей обратно, упорядочив по дате». Эксперимент исходит из идеи, что если модель работает идеально, после двух таких операций документ совпал бы с исходником. Посылка в целом справедлива для стандартизированных форм, хотя я сразу задумалась о том, справился ли бы человек с такой задачей идеально. Пары правок сцепляются в цепочку из 10 раундов — 20 последовательных взаимодействий, и в финале результат сравнивается с исходником по доменно-специфичным метрикам.

Сравнивали 19 LLM, причём все ключевые современные, которыми (несмотря на выходы уже следующих версий) многие реально сейчас пользуются: Claude 4.6 Opus, GPT-5.4, Gemini 3.1 Pro. И именно у этих, лучших, средняя деградация — 25%. У остальных — больше, у худших — до 90%. Кроме того, оказалось, что слабые модели чаще удаляют контент (это заметить легче — стало короче), а фронтирные модели чаще искажают существующий — текст выглядит нетронутым, но смысл уплыл. То есть использование топовых моделей с этой точки зрения может быть проблематичнее, снижается бдительность при их использовании, и ошибки отловить сложнее.

И что важно вынести из описания эксперимента — это ловушка названия: когда юрист видит в заголовке your documents, он думает об условном договоре поставки в Word. Но documents в этом исследовании — это разнообразные структурированные форматы, о которых я лично никогда и не слышала (.cif, .obj, .ledger???). Юридических или просто офисных документов в выборке нет.

Ну то есть можно не переживать?

Это, конечно, личное дело каждого, но некоторые наблюдения и выводы в статье мне кажутся универсальными и применимыми и к нам!

Это исследование родилось не на пустом месте: редактирование структурированных и полуструктурированных документов — это одна из самых массовых категорий использования LLM в реальной работе (что подтверждают и собственные данные Microsoft и Anthropic). Авторы сознательно выбрали такой тип задач и документов, где ошибки опаснее всего и заметнее меньше всего — ошибки не субъективные, а фактологические, вычленить их в массивах данных глазами тяжело. У юристов такие задачи в целом тоже есть, когда нужна работа с различными таблицами, реестрами, выписками: навскидку кажется, что это очень актуально для банкротчиков, налоговиков, аудиторов.

Одно из важных наблюдений состоит в том, что модели не «портят» документы постепенно. Девять правок из десяти они выполняют почти идеально, а потом одна ломает что-то на 10–30% за шаг. На эти редкие срывы приходится 80% всей наблюдаемой деградации. Авторы называют это sparse but severe — редкие, но серьёзные ошибки.

В творческой работе такой провал можно заметить сразу, а в реестре требований кредиторов на тысячи строк — ну попробуй! И что характерно, статья прямо называет, какой класс операций особенно склонен к таким срывам: split-and-merge и классификация, то есть глобальная реструктуризация документа. И для юридических сценариев это вполне характерная задача (собрать из нескольких документов один, один разделить на несколько и переставить куски местами). Не исключено, что выводы статьи для юридических и подобных документов могут быть даже более применимы, чем для измеренных 52 доменов (но чтобы это измерить, нужно очень сильно заморочиться за сбор документов и дизайн эксперимента).

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

Мысли о нашей специфики

Юридические документы — интересный гибрид. Они не формально-структурированы, как .ledger или .obj, у нас нет строгой грамматики, формулировки многозначны (иногда целенаправленно), смысл несёт связный текст. Но в то же время они гораздо менее толерантны к мелким искажениям, чем художественный текст. Методологией DELEGATE-52 такие документы измерять не получится, так как нет естественной обратимости, наши сценарии, как правило, текстовые: надрафтить, переформулировать, изменить тональность. Кроме того, тестировался только one-turn режим (один проход), а в нашей реальной работе диалог многоходовый — и в отдельной работе тех же авторов показано, что в многопроходовом режиме деградация ещё выше. Методология измеряет сохранность содержимого, а не корректность, и поэтому применима только для какого-то небольшого кусочка нашей работы. Собственно, авторы в README репозитория бенчмарка прямо пишут:

We do not recommend using DELEGATE-52 in commercial or real-world applications, nor in the context of high-risk decision making (e.g. in law enforcement, legal, finance, or healthcare).

В целом эта статья особо ничего не меняет в наших практиках использования LLM, и, возможно, это тоже важно зафиксировать: на май 2026 года продолжаем перепроверять за моделями, но с большей awareness имеем в виду, что:

• 5 прекрасных результатов в рамках одного чата не гарантируют классный результат на 6-м промпте: чем длиннее сессия, тем выше шанс встретить тот самый sparse-but-severe сбой. Лучше короткие сессии и периодический возврат к чистой версии, чем три часа дошлифовки в одном чате;
• Cowork и другие мультиагенты никакой дополнительной страховки от ошибок и деградации не дают (безусловно, многократно ускоряют и позволяют покрыть большие объёмы, но и требуют больше хлопот с организацией работы в них);
• в контекстном менеджменте важно не переборщить: может и сам разберётся и найдёт то, чего вы сами не заметили, а может именно перегруженность контекста и черрипикинг из него будут причиной резкой и внезапной деградации.

Для меня лично эта статья стала некоторым утешением в том, насколько сложно даже в Microsoft проводить подобные исследования без оговорок и множества ограничений (а то я всё ещё переживаю). Очень интересно, какие изменения претерпит статья после ревью!