Исследование Microsoft: LLM хуже всего справляются с редактированием рабочих документов, но Python — исключение

Новое исследование тройки исследователей Microsoft показывает, что LLM «вносят существенные ошибки при редактировании рабочих документов».

Тесты того, насколько хорошо 19 больших языковых моделей (LLM) справляются со сложными многошаговыми задачами, показали, что они и склонны к ошибкам, и во многих случаях ненадежны.

Результаты представлены в препринте LLMs Corrupt Your Documents When You Delegate, авторами которого выступили исследователи Microsoft Philippe Laban, Tobias Schnabel и Jennifer Neville. В основе работы лежит созданный ими бенчмарк DELEGATE-52, который позволил им моделировать рабочие процессы, похожие на задачи знанийного сотрудника. Сейчас статья находится на рецензировании.

По их словам, бенчмарк включает 310 рабочих сред в 52 профессиональных доменах, включая кодинг, кристаллографию, генеалогию и нотную запись. Каждая среда состоит из реальных документов общим объемом около 15K токенов и пяти-десяти сложных задач редактирования, которые пользователь может попросить LLM выполнить.

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

По словам авторов, ошибки значимы. «Результаты показывают, что современные LLM вносят существенные ошибки при редактировании рабочих документов: передовые модели (Gemini 3.1 Pro, Claude 4.6 Opus и GPT 5.4) в среднем теряют 25% содержания документа за 20 делегированных взаимодействий, а средняя деградация по всем моделям составляет 50%».

Эксперт оценил бенчмарк положительно

Brian Jackson, директор по исследованиям в Info-Tech Research Group, назвал результаты очень интересными. «Проверка набора LLM в разных рабочих доменах дает множество полезных инсайтов», — сказал он. — «Думаю, такой бенчмарк может быть полезен корпоративным разработчикам, которые хотят использовать agentic AI для автоматизации конкретных процессов и понять пределы того, чего можно добиться».

Однако, по его словам, «не стоит делать вывод, что раз эти foundation models ухудшали документ после 20 правок, их нельзя использовать для автоматизации работы в определенной области. Это лишь означает, что в текущем виде они не могут выполнять всю работу».

Jackson также отметил: «В корпоративной среде, где критически важен точный результат, вы бы не стали подходить к задаче так. Вы бы выстроили поток автоматизации с более жесткими guardrails, чтобы предотвращать ошибки. Это можно сделать с помощью нескольких агентов, играющих разные роли, например одного, который вносит правки, и другого, который проверяет ошибки и исправляет их».

Sanchit Vir Gogia, главный аналитик Greyhound Research, сказал: «Статью Microsoft следует читать как серьезное предупреждение о delegated AI, а не как утверждение, что enterprise AI провалился. Это важное различие. Статья по-прежнему является препринтом, поэтому к ней нужно относиться осторожно, но ее центральный вопрос — ровно тот, который должны задавать CIO: может ли AI сохранять целостность сложной работы при повторной делегации?»

Исследование, по его словам, сильнее того, что он назвал «обычным театром AI-бенчмарков», потому что оно тестирует рабочие продукты, а не просто ищет остроумные ответы на один шаг. «В нем используются обратимые задачи редактирования, отраслевые оценщики и метод round-trip, чтобы проверить, возвращается ли документ целым после повторных правок. Во многих случаях — нет».

В этом и состоит суть, пояснил Gogia. «Речь не только о hallucinations. Речь о целостности артефакта».

AI пока «недостаточно надежен»

Он добавил, что главный вывод «неприятен: даже самые сильные модели к концу длинных рабочих процессов портят примерно четверть содержимого документа, а средняя деградация по всем протестированным моделям достигает примерно 50%. Статья также показывает, что производительность резко отличается по доменам. Python — единственный домен, где большинство моделей “готовы”, а лучшая модель достигает этого порога только в 11 из 52 доменов».

AI, по словам Gogia, не проваливается потому, что не умеет писать, — он проваливается потому, что пока не умеет сохранять.

Как он указал, исследование особенно полезно потому, что показывает, как накапливаются ошибки. Большие документы ухудшают результат. Более длинное взаимодействие ухудшает результат. Отвлекающие файлы ухудшают результат. Короткие тесты льстят системе, тогда как длинные рабочие процессы ее вскрывают. Это довольно точно соответствует корпоративной реальности, где работа бывает хаотичной, файлы устаревают, контекст шумный, а самые важные документы редко бывают самыми простыми.

Честный вывод, сказал он, «не в том, что AI нужно держать вне корпоративных процессов. Он в том, что delegated AI пока недостаточно надежен, чтобы оставлять его один на один с важными артефактами».

Когда AI редактирует важный документ — например, контракт, бухгалтерскую книгу, политику, codebase, доклад для совета директоров или compliance record, — ответственность за ущерб все равно несет компания, предупредил Gogia.

Подходы к снижению рисков

Чтобы предотвратить такой ущерб, Jackson предложил компаниям дополнительно обучать и донастраивать модели под собственные рабочие процессы: «Эти foundation models очень хорошо справляются со множеством разных задач, но хуже — с одной конкретной задачей на действительно высоком уровне. Поэтому компаниям, которые хотят добиться именно этого, может потребоваться улучшать сами модели, обучая их на собственных данных».

Например, «[статья Microsoft] указывает на одну multi-agent конфигурацию, которая привела к большей деградации, а не к меньшей, так что метод выявления деградации должен быть хорошо спроектирован, чтобы быть эффективным», — сказал он. «Другой подход, который внедрили некоторые корпоративные платформы, — детерминированная проверка точности результата с помощью математической верификации. Поэтому знание того, какие домены сложнее автоматизировать одной LLM, полезно: разработчики могут заранее добавить в процесс больше этапов проверки».

Он сказал: «В зависимости от модели — например, полностью ли она open source или проприетарная — у вас может быть больше гибкости в том, насколько сильно ее можно кастомизировать. Так что корпоративный разработчик может посмотреть на эти результаты, выбрать LLM, лучше всего автоматизирующую нужный домен, а затем отправить ее на дополнительное обучение, чтобы довести процесс до совершенства».

Люди не исчезают

По словам Gogia, статья показывает нечто более точное, чем просто «AI по-прежнему нужны люди». «Она показывает, что AI меняет человеческий слой: из производства — в надзор, валидацию и ответственность. Это совсем другая операционная модель, чем та, которую часто продают в разговорах на уровне совета директоров».

Люди, сказал он, «не исчезают. Меняется их работа. И это неприятная часть для компаний, стремящихся сокращать штат. Те, кто лучше всего замечает ошибки AI, часто и есть те самые сотрудники, которых организация хочет заменить, сократить или перевести на другие задачи. Уберите слишком много domain expertise из процесса — и компания одновременно уберет людей, которые знают, когда AI тихо повредил работу».

Экспертность становится ценнее, а не менее важной, добавил Gogia: «Статья подтверждает это, потому что более сильные модели не просто удаляют контент. Они часто его искажают. Слабые модели легче поймать, когда они явно теряют материал. Передовые модели сложнее, потому что содержание остается на месте, но становится неверным, искаженным или слегка измененным. Это требует знающей проверки, а не поверхностного просмотра».

Эта статья первоначально появилась на CIO.com.

Материал — перевод статьи с английского.

Оригинал: AI is ready to take over Python programming, but not much else