惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
The GitHub Blog
The GitHub Blog
博客园 - 【当耐特】
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Recent Announcements
Recent Announcements
D
Docker
GbyAI
GbyAI
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
The Cloudflare Blog
雷峰网
雷峰网
A
About on SuperTechFans
小众软件
小众软件
博客园 - Franky
博客园 - 聂微东
F
Full Disclosure
大猫的无限游戏
大猫的无限游戏
C
Check Point Blog
MongoDB | Blog
MongoDB | Blog
G
Google Developers Blog
Microsoft Azure Blog
Microsoft Azure Blog
U
Unit 42
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
V2EX
Engineering at Meta
Engineering at Meta
宝玉的分享
宝玉的分享
aimingoo的专栏
aimingoo的专栏
量子位
P
Proofpoint News Feed
Hugging Face - Blog
Hugging Face - Blog
博客园_首页
罗磊的独立博客
Martin Fowler
Martin Fowler
D
DataBreaches.Net
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
S
Secure Thoughts
Project Zero
Project Zero
L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志
C
Cybersecurity and Infrastructure Security Agency CISA
T
Tailwind CSS Blog
S
Schneier on Security
Blog — PlanetScale
Blog — PlanetScale
The Hacker News
The Hacker News
Spread Privacy
Spread Privacy
Security Latest
Security Latest
NISL@THU
NISL@THU
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
C
CXSECURITY Database RSS Feed - CXSecurity.com
J
Java Code Geeks

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Перевод: LLMs Corrupt Your Documents When You Delegate от Microsoft
catprokhorov · 2026-05-05 · via Все публикации подряд на Хабре

Это перевод научной статьи от исследователей компании Microsoft. Статья была опубликована 17 апреля 2026 года. См. источник

Большие языковые модели (LLM) готовы кардинально изменить сферу интеллектуального труда за счёт появления делегированной работы как новой парадигмы взаимодействия (например, «vibe coding»). Делегирование требует доверия — ожидания, что LLM добросовестно выполнит задачу, не добавляя ошибок в документы. Мы представляем DELEGATE-52 для изучения готовности систем ИИ к делегированным рабочим процессам. Эта модель создаёт длинные делегированные рабочие процессы, требующие глубокого редактирования документов в 52 профессиональных областях, таких как программирование, кристаллография и нотная запись. Наш крупномасштабный эксперимент с 19 LLM показывает, что современные модели ухудшают качество документов при делегировании: даже передовые модели (Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4) повреждают в среднем 25% содержания документов к концу длинных рабочих процессов, а другие модели дают еще более серьезные сбои. Дополнительные эксперименты показывают, что использование инструментов агентов не влияет на производительность DELEGATE-52. Ухудшения качества напрямую зависит только от размера документа, продолжительностью взаимодействия или наличия файлов-отвлекателей. Наш анализ показывает, что современные LLM являются ненадежными: они вводят редкие, но серьезные ошибки, которые незаметно повреждают документы, накапливаясь в ходе длительного взаимодействия.

Рисунок 1: Наглядные примеры того, как большие языковые модели (LLM) повреждают документы в ходе длительных рабочих процессов в тесте DELEGATE-52. При редактировании файлов, содержащих графические диаграммы, узоры или 3D-объекты, LLM вносят редкие, но серьезные ошибки, которые незаметно повреждают документы, а их последствия накапливаются в ходе длительного взаимодействия.

Рисунок 1: Наглядные примеры того, как большие языковые модели (LLM) повреждают документы в ходе длительных рабочих процессов в тесте DELEGATE-52. При редактировании файлов, содержащих графические диаграммы, узоры или 3D-объекты, LLM вносят редкие, но серьезные ошибки, которые незаметно повреждают документы, а их последствия накапливаются в ходе длительного взаимодействия.

1. Введение

Последние достижения в области больших языковых моделей (LLM) открывают путь к новым парадигмам взаимодействия, таким как делегирование задач (Shao et al., 2025; Ulloa et al., 2025), когда специалисты контролируют работу LLM, выполняющих задачи от их имени (например, «vibe coding»). Важно отметить, что пользователи, делегирующие работу, могут не иметь достаточной экспертизы или времени для проверки изменений, внедрённых LLM, и вынуждены доверять тому, что LLM не вносит ошибок, таких как галлюцинации или удаления.

Жизнеспособность такой делегированной работы зависит от способности LLM выполнять задачи и манипулировать документами в конкретной области без ошибок. Мы изучаем с помощью моделирования готовность современных LLM к делегированной работе в широком спектре профессий.

Первым вкладом нашей работы является DELEGATE-52 — набор тестовых данных (бенчмарк), включающий 310 рабочих сред из 52 профессиональных областей, в том числе программирование, кристаллографию, генеалогию и нотную запись. Каждая среда состоит из реальных документов общей длиной около 15 тысяч токенов и 5–10 сложных задач редактирования, которые пользователь может поручить выполнить LLM. Это существенно отличается от предыдущих работ, которые фокусировались на задачах в рамках одной области (например, редактирование кода (Cassano et al., 2023) или редактирование текста (Spangher et al., 2022)).

Нашим вторым вкладом является метод моделирования реле с циклическим опросом, который позволяет моделировать делегированное взаимодействие с длительным горизонтом и оценивать производительность LLM без необходимости аннотирования или эталонных решений. В частности, мы предполагаем, что каждая задача редактирования является обратимой и определяется прямой и обратной инструкцией. Последовательное применение обеих инструкций формирует цикл обратного перевода, который при идеальной модели точно восстанавливает исходные документы. Это позволяет нам оценивать производительность путем измерения сходства документов до и после кругового цикла. Круговые циклы можно далее компоновать последовательно, формируя ретрансляцию. Обратный перевод возник как метод расширения данных и оценки в машинном переводе (Sennrich et al., 2015; Somers, 2005) и недавно был адаптирован для оценки согласованности LLM посредством цепочки обратимых преобразований (Hong et al., 2025; Allamanis et al., 2024). Мы переориентируем этот метод для изучения делегированного взаимодействия с длительным горизонтом.

Нашим третьим вкладом является масштабное моделирование с участием 19 LLM на наборе данных DELEGATE-52. Наши результаты показывают, что современные модели допускают существенные ошибки при редактировании рабочих документов: передовые модели (Gemini 3.1 Pro, Claude 4.6 Opus и GPT 5.4) теряют в среднем 25 % содержания документа за 20 делегированных взаимодействий, а средний уровень ухудшения качества по всем моделям составляет 50 %. Степень ухудшения зависит от области: LLM демонстрируют лучшие результаты в программных областях (Python, базы данных) и худшие — в области естественного языка и нишевых областях (например, финансовые отчеты, нотная запись). Мы определяем модель как «готовую» к делегированной работе в той или иной области, если она достигает результата 98% или выше после 20 взаимодействий. Python — единственная область (из 52), в которой большинство моделей готовы, что подчеркивает сохраняющийся значительный разрыв.

Наконец, целенаправленные эксперименты позволяют уточнить наше понимание текущих возможностей LLM. Мы подтверждаем, что такие известные факторы, как размер документа, продолжительность взаимодействия и контекст отвлекающих факторов, способствуют ухудшению результатов (Liu et al., 2023; Shi et al., 2023), однако эти негативные эффекты накапливаются с течением времени, а это означает, что короткие симуляции недооценивают их серьезность. Мы также обнаружили, что использование базовой агентской обвязки не улучшает производительность LLM, которые мы тестируем на DELEGATE-52, и что производительность после двух взаимодействий не позволяет предсказать производительность в долгосрочной перспективе (20 взаимодействий), что подтверждает важность долгосрочной оценки. Мы публикуем DELEGATE-52 в качестве инструмента для мониторинга готовности ИИ к делегированной работе и стимулирования исследований в области долгосрочного взаимодействия человека и ИИ.

2. Бенчмарк DELEGATE-52

Рисунок 2: обратный перевод с циклическим опросом

Рисунок 2: обратный перевод с циклическим опросом

В DELEGATE-52 мы моделируем длинные рабочие процессы, которые могут входить в круг обязанностей специалиста, работающего с информацией. Рабочий процесс состоит из исходных документов и другого контента, которые преобразуются посредством последовательности сложных операций редактирования, что отражает итеративный характер делегированной работы. В данной статье мы представляем методологию, которая позволяет (i) выполнять оценку автоматически и (ii) масштабировать длину рабочих процессов.

2.1 Оценка без использования референсов

На рисунке 2 изображена простейшая операция, состоящая из пары задач редактирования, вдохновленная методом обратного перевода (Somers, 2005). Имея исходный документ s, мы можем определить пару инструкций по прямому и обратному редактированию (x^→,x^←), которые описывают на естественном языке преобразование исходного документа и его обратное преобразование (σ, σ^{−1}). Сначала LLM применяет инструкцию прямого редактирования к исходному документу, получая преобразованный документ t=σ​(s)=LLM​(s;x^→). Затем LLM применяет инструкцию обратного редактирования к преобразованному документу, получая реконструированный документ ŝ=σ^{−1}​(t)=LLM​(t;x^←). Каждый шаг выполняется как независимая сессия, состоящая из одного хода.

Для измерения качества реконструкции мы реализуем доменно-специфическую функцию сходства sim ​ ( s _i , s_ j ). Идеальная модель дает sim(s, ŝ) = 1, сводя оценку к семантическому эквиваленту без справочных аннотаций. Чтобы обратный перевод соответствовал производительности модели, модели должны искренне пытаться выполнять инструкции по редактированию, а не идти по пути наименьшего сопротивления.

Моделирование длинных рабочих процессов

Поскольку каждый цикл рассчитан на возвращение к исходному документу, их можно объединять в более длинные рабочие процессы. Мы выбираем N пар инструкций (x_1^→,x_1^←), … ,(x_N^→,x_N^←) из набора доступных вариантов, каждая из которых представляет собой преобразование σ_i​(s). Мы моделируем n-ступенчатый процесс, последовательно применяя n циклов редактирования:

   ŝ_k = ( σ_1 ∘ σ _1^ − 1 ∘ ⋯ ∘ σ_ n ∘ σ_ n^− 1 ) ​ ( s ) ,    1 ≤ n ≤ N

Нашим основным показателем является оценка реконструкции после k взаимодействий (т. е. k/2 циклов):

  RS ​ @ ​ k ​ ( s ) = sim ​ ( s , ŝ_{k / 2}) .

2.2 Состав бенчмарка

Мы отобрали 52 профессиональных области для моделирования рабочих процессов (перечислены на рисунке 3), представляющие различные профессии в сфере интеллектуального труда в пяти категориях: «Наука и инженерия», «Код и конфигурация», «Творчество и медиа», «Структурированные записи» и «Повседневная деятельность». Ключевым критерием включения является наличие стандартного типа документа, представляющего собой текстовый файл без кодировки (например, .srt для субтитров, .cif для кристаллографии). Вторичные факторы, учитываемые при выборе областей, перечислены в Приложении K.1.

Рисунок 3: DELEGATE-52 включает рабочие среды из 52 профессиональных областей, сгруппированных в пять категорий: «Наука и инженерия», «Программный код и конфигурация», «Творчество и медиа», «Структурированные записи» и «Повседневная жизнь».

Рисунок 3: DELEGATE-52 включает рабочие среды из 52 профессиональных областей, сгруппированных в пять категорий: «Наука и инженерия», «Программный код и конфигурация», «Творчество и медиа», «Структурированные записи» и «Повседневная жизнь».

2.2.1 Условия работы

Для каждой области мы создаем шесть рабочих сред, состоящих из исходного документа, набора из 5–10 возможных задач по редактированию и отвлекающего контекста. Пример рабочей среды для области бухгалтерского учета представлен на рисунке 4, а подробное описание процесса создания сред приведено в Приложении K.

Рисунок 4: Пример рабочей среды из области бухгалтерского учета в DELEGATE-52. Исходным документом служит бухгалтерская книга Hack Club, некоммерческой организации. Выделенная операция редактирования («Разделение по категориям») заключается в том, чтобы сначала разделить исходный документ hack_club.ledger на отдельные файлы по категориям расходов (задача редактирования в прямом направлении), а затем объединить их обратно в один файл в хронологическом порядке (задача редактирования в обратном направлении).

Рисунок 4: Пример рабочей среды из области бухгалтерского учета в DELEGATE-52. Исходным документом служит бухгалтерская книга Hack Club, некоммерческой организации. Выделенная операция редактирования («Разделение по категориям») заключается в том, чтобы сначала разделить исходный документ hack_club.ledger на отдельные файлы по категориям расходов (задача редактирования в прямом направлении), а затем объединить их обратно в один файл в хронологическом порядке (задача редактирования в обратном направлении).

Исходные документы.

Исходный документ является отправной точкой для всех симуляций. Они представляют собой реальные документы, найденные в Интернете (без использования синтетических данных, образцов или шаблонов), их объем составляет от 2 до 5 тысяч токенов и они распространяются по лицензии, разрешающей их повторное распространение. Вторичные требования перечислены в Приложении N. В симуляциях на рисунке 1 используются три исходных документа: схема архитектуры ядра Linux (график), узор «твилл-ромб» с 12-ю перекрещивающимися линиями (текстиль) и пальма ActionBoy (3D-объекты).

Задачи редактирования.

Задачи редактирования представляют собой пары инструкций «вперед» и «назад», определяющих обратимые преобразования. Эти инструкции должны: (1) отражать реальные рабочие задачи, которые заинтересованное лицо может выполнять при работе с документом, (2) требовать глубокого, нетривиального преобразования контекста, выходящего за рамки простого расширения. Другими словами, σ​(s) не может быть разложено на [s,σ^′​(s)](конкатенация), так как это сделало бы обратное редактирование тривиальным (обрезание). Каждая задача редактирования помечается семантическими операциями, необходимыми для выполнения редактирования (например, числовые преобразования, классификация, разделение). Рабочая среда бухгалтерского учета на рисунке 4 содержит 10 задач редактирования, включая задачи, требующие разделения бухгалтерской книги на отдельные файлы по категориям расходов или получателям возмещения, преобразования сумм в евро или форматирования бухгалтерской книги в формате Beancount. В приложении K.4 описан процесс создания и маркировки задач редактирования.

Отвлекающий контекст.

В реальных рабочих условиях найденные или доступные документы не всегда имеют отношение к выполняемой задаче (т. е. точность поиска не идеальна). Чтобы смоделировать эту ситуацию, каждая рабочая среда включает контекст отвлекающих факторов: тематически связанные документы, которые не мешают выполнению каких-либо задач по редактированию. В примере с бухгалтерским учетом на рисунке 4 контекст отвлекающих факторов включает план счетов, политику организации по возмещению расходов и три других документа организации. Такие контексты варьируются от 8 до 12 тысяч токенов на среду и по умолчанию включаются в эксперименты для повышения реалистичности моделирования. Создание отвлекающих факторов и проверка отсутствия помех подробно описаны в Приложении K.7.

2.2.2 Оценка с учетом специфики области

Рисунок 5: Вверху: домены в DELEGATE-52 реализуют функцию разбора, которая преобразует текстовые документы в структурированное представление, которое затем используется функцией оценки схожести для присвоения баллов двум проанализированным экземплярам. Внизу: конкретный пример для домена рецептов.

Рисунок 5: Вверху: домены в DELEGATE-52 реализуют функцию разбора, которая преобразует текстовые документы в структурированное представление, которое затем используется функцией оценки схожести для присвоения баллов двум проанализированным экземплярам. Внизу: конкретный пример для домена рецептов.

Обычные методы оценки текстового сходства учитывают либо низкоуровневое совпадение (например, коэффициент Левенштейна (Levenshtein, 1965)), либо семантическое расстояние в общем пространстве вложений (Neelakantan et al., 2022). Эти подходы не позволяют адекватно отразить мелкомасштабные семантические изменения, поэтому мы реализуем индивидуальную функцию сходства для каждой области, как показано на рисунке 5.

Семантическое сходство измеряется в два этапа: разбор и оценка. Функция разбора преобразует документы в структурированное представление. На рисунке 5 рецепт разбивается на ингредиенты (названия, количества, единицы измерения), этапы и советы. Затем функция сходства сравнивает два разбитых представления и выдает оценку в диапазоне [0, 1]. В домене рецептов сходство представляет собой взвешенную сумму списков ингредиентов (40%), шагов (40%) и советов (20%). Комбинация компонентов для каждого домена и их относительные веса калибруются с помощью тестирования абляции, чтобы обеспечить пропорциональную чувствительность к потере или повреждению контента (Приложение K.2).

Такая гибкость позволяет осуществлять адаптированное к конкретной области взвешивание различных компонентов функции оценки. Например, небольшое изменение на поверхностном уровне в составе ингредиента (например, 200 → 800 г сливочного масла) может серьезно повлиять на общую оценку (как и требуется). И наоборот, разбор, специфичный для конкретной области, обеспечивает устойчивость функции оценки: изменения на поверхностном уровне, не влияющие на семантику (например, 200 г против 0,2 кг сливочного масла или перестановка порядка в списке ингредиентов), не влияют на оценку.

Реализация устойчивого семантического эквивалента для 52 доменов является центральным элементом нашей методологии. В Приложении C мы показываем, что общие меры сходства (включая LLM-as-a-judge с GPT 5.4) не способны уловить нюансы семантических различий, лишь умеренно коррелируя с нашей метрикой, основанной на разборе, и улавливая не более 25% дисперсии.

2.2.3. Quality Assurance.

Для обеспечения достоверности эксперимента мы проводили контроль качества на каждом этапе процесса построения (Приложение K), оценивая (1) устойчивость синтаксического анализа, (2) чувствительность оценки, (3) тестирование редактирования и (4) влияние отвлекающих элементов.

3. Эксперименты

Выбор моделей.

Мы отобрали 19 LLM из шести семейств: OpenAI (GPT 4o, GPT 4.1, GPT 5 Nano, GPT 5 Mini, GPT 5 Chat, GPT 5, GPT 5.1, GPT 5.2, GPT 5.4, o1, o3 и GPT OSS 120B), Anthropic (Claude 4.6 Sonnet и Claude 4.6 Opus), Google Gemini (3 Flash и 3.1 Pro), Mistral (Large 3), xAI (Grok 4) и Moonshot (Kimi K2.5). Выбор охватывает широкий спектр возможностей, от небольших до передовых моделей, что позволяет нам изучить, как масштаб и архитектура модели влияют на снижение качества при делегировании задач. Точные версии моделей приведены в Приложении L.

4 Результаты

Результаты приведены в таблице в источнике

4.1 Основные выводы

В таблице 1 приведены подробные результаты моделирования. В целом, производительность всех моделей снижается по мере взаимодействия: среднее снижение производительности по всем протестированным моделям составило 50 %. Даже передовые модели (Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4) демонстрируют снижение качества документов в среднем на 25 % за 20 взаимодействий.

Разбивка результатов по завершении симуляции по отдельным областям (табл. 2) показывает, что модели не готовы к делегированным рабочим процессам в подавляющем большинстве областей: в 80 % наших симулированных условий модели приводят к серьезному повреждению документов (ухудшение качества не менее чем на 20 %). Домен Python является исключением: большинство протестированных моделей (17 из 19) обеспечивают манипуляции без потерь, что согласуется с недавними выводами по делегированным рабочим процессам написания кода (Pimenova et al., 2025). Лучшая модель (Gemini 3.1 Pro) признана готовой (RS@20 ≥ 98%) в 11 из 52 доменов.

Мы обнаружили, что краткосрочные результаты (после 2 взаимодействий) не всегда позволяют предсказать результаты в долгосрочной перспективе. Например, GPT 5 и Kimi K2.5 демонстрируют почти одинаковую производительность после двух взаимодействий (91,5 против 91,1), но со временем резко расходятся (завершая с результатами 48,3 против 64,1). И наоборот, Gemini 3 Flash отстает от Mistral Large 3 на 6,4 балла на раннем этапе (76,0 против 82,4), но обгоняет его к концу симуляции (35,8 против 35,5). Другими словами, симуляции с небольшим количеством взаимодействий недостаточны для понимания производительности LLM в долгосрочной перспективе, что подтверждает важность тестов, моделирующих длительные взаимодействия.

Мы обращаем внимание читателя на то, что абсолютные оценки следует рассматривать с учетом масштабов нашей экспериментальной постановки. Модели тестируются в симуляционной среде, где в ходе 20 взаимодействий требуется выполнить работу с документами объемом 3–5 тыс. токенов, а также с отвлекающим контекстом объемом 8–12 тыс. токенов. В следующих подразделах на примере поднабора моделей семейства GPT исследуется, как использование инструментов, размер документа, продолжительность взаимодействия и наличие отвлекающих факторов влияют на снижение качества результатов.

4.2 Agent (With Tools) vs. LLM (Without Tools)

В основном эксперименте модели работают без использования инструментов, напрямую выводя отредактированные файлы. В принципе, использование инструментов могло бы снизить уровень ухудшения качества, позволяя моделям вносить целенаправленные программные изменения (например, с помощью функции «найти и заменить» или выполнения кода) вместо полного перегенерирования документов, что снижает риск непреднамеренного повреждения контента. Чтобы проверить это, мы реализовали базовую агентскую среду (Yao et al., 2022) с инструментами чтения, записи файлов и выполнения кода (Приложение M). Отметим, что это не оптимизированная система агентов, соответствующая современному уровню развития техники; в будущих работах можно было бы исследовать более сложные среды.

Результаты обобщены в таблице 4. Четыре протестированные модели демонстрируют худшие результаты при агентском управлении с использованием инструментов, чем без них, что приводит к дополнительному снижению производительности в среднем на 6% к концу симуляции. Модель с наилучшими показателями (GPT 5.4) сокращает этот разрыв, демонстрируя дополнительное снижение производительности всего на 3% (71,5% против 68,3%).

На первый взгляд это кажется противоречащим здравому смыслу: ведь инструменты должны давать LLM преимущество. Однако здесь играют роль несколько факторов. Во-первых, при использовании инструментов модели несут дополнительную нагрузку (см. таблицу 4) из-за интерактивного характера агентной системы; для выполнения задачи они в среднем запускают 8–12 инструментов, потребляя в 2–5 раз больше входных токенов, чем при выполнении задачи без инструментов. Сохранение производительности LLM в условиях длинного контекста является известной проблемой для современных LLM (Liu et al., 2023; Laban et al., 2024). Во-вторых, DELEGATE-52 не содержит задач, которые можно легко выполнить путем запуска короткой программы (таких как сортировка таблицы), поскольку это не было бы типичным примером задачи, которую пользователь делегировал бы LLM. Задачи могут включать вычисления, но также должны требовать понимания текста и рассуждений над документами. Это объясняет, почему даже в агентских настройках LLM предпочитают инструмент записи файлов, а не выполнение кода (см. таблицу 4), что ограничивает преимущества использования агентов. Если посмотреть на тенденцию: лучшие модели в большей степени полагаются на выполнение кода (10% для GPT 4.1 против 45% для GPT 5.4), что приводит к большей эффективности использования агентской обвязки.

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

4.3 Влияние размера документов

Результаты экспериментов с изменением объёма документа представлены в таблице 6. Вкратце, по мере увеличения объёма документа с 1 тыс. до 10 тыс. токенов показатели GPT 5.4 постепенно ухудшаются, и к концу моделирования при объёме 10 тыс. токенов они составляют 59,9 %. Каждые дополнительные 1000 токенов в документе ухудшают способность GPT 5.4 сохранять содержание примерно на 0,7% после двух взаимодействий, но на 3,6% после 20 взаимодействий: ∼5-кратное увеличение в ходе взаимодействия. Одним словом, размер документа и продолжительность взаимодействия складываются мультипликативно: ухудшение качества из-за увеличения размера документа нарастает лавинообразно в ходе взаимодействия.

4.4 Продолжительность взаимодействия

В основном эксперименте используется ретрансляция длительностью 10 циклов (20 взаимодействий). В таблице 6 мы увеличиваем длительность ретрансляции для подмножества моделей до 50 циклов (100 взаимодействий). Мы не создавали дополнительных преобразований, а просто повторяли существующие по принципу круговой очереди.

Мы обнаружили, что ухудшение качества продолжает накапливаться в более длинных ретрансляциях, при этом ни одна из моделей не демонстрирует признаков стабилизации. Темпы ухудшения замедляются: на первую половину расширенной ретрансляции (циклы 5–25) приходится примерно в 2–3 раза больше потерь, чем на вторую (25–50), но даже самая сильная модель (GPT 5.4) опускается ниже 60% к концу ретрансляции из 50 циклов. Подводя итог, можно сказать, что при увеличении длины ретрансляций с 10 до 50 циклов производительность продолжает снижаться, причем модели вводят новые ошибки даже при повторении задач.

4.5 Эффект отвлекающих документов

В проведенных до сих пор экспериментах в ходе моделирования использовались отвлекающие документы: это позволяет воссоздать реалистичную рабочую среду, в которой не все найденные документы необходимы для выполнения задачи (т. е. точность поиска не идеальна). Мы упрощаем эксперимент, проводя моделирование без учета отвлекающих документов. Это упрощает условия: LLM получает ровно те документы, которые необходимо отредактировать, без необходимости оценивать релевантность информации.

В таблице 8 приведены результаты для четырех моделей, в которых сравнивается производительность каждой модели с включенными и исключенными отвлекающими документами. Если рассматривать начальные этапы симуляции (2 взаимодействия), удаление отвлекающих документов дает небольшой положительный эффект, повышая результаты на 0,4–4%. Однако по мере развития взаимодействия влияние отвлекающих факторов усиливается, и к концу симуляции мы наблюдаем улучшение результатов на 2–8%. Другими словами, вред от отвлекающих факторов усиливается с увеличением продолжительности взаимодействия, и измерение краткосрочного эффекта отвлекающих факторов, вероятно, недооценивает их влияние в длительных, реалистичных взаимодействиях. Этот вывод перекликается с предыдущими работами по отвлекающему нерелевантному контексту (Shi et al., 2023) и расширяет их на условия с длительным горизонтом. Это имеет значение для оценки систем поиска: тестовые наборы данных с длительным горизонтом позволяют зафиксировать долгосрочное влияние усовершенствованного поиска на производительность.

4.6 Делегирование вне текстовых документов

Чтобы проверить, распространяется ли наша методология за пределы текста, мы реализовали шесть визуальных рабочих сред, имитирующих рабочие процессы редактирования изображений (подробности см. в Приложении J), и протестировали 9 моделей с возможностями генерации изображений в ходе до 20 взаимодействий.

Примеры результатов ретрансляции редактирования показаны в галерее на рисунке A5, а оценки обобщены в таблице 8. Мы наблюдаем, что ухудшения при манипуляции изображениями гораздо более выражены, чем в текстовых областях. Лучшие модели достигают конечных оценок реконструкции 28–30 %, по сравнению с 70–80 % для текстовых областей. Даже после двух взаимодействий ни одна модель генерации изображений не превышает 65%, что хуже, чем у текстовых моделей после 20 взаимодействий. Этот небольшой эксперимент показывает, что модели редактирования изображений ухудшают качество документов гораздо сильнее, чем текстовые модели, и не готовы к делегированной работе. Этот также показывает, что наша методология распространяется и на нетекстовые модальности.

5. Анализ

Критические сбои (Приложение E)

Основные результаты (табл. 1) представляют собой усредненные показатели ухудшения качества по результатам сотен симуляций для каждой модели, что создает впечатление плавных кривых ухудшения, причем каждое взаимодействие приводит к небольшому дополнительному ухудшению. Чтобы выйти за рамки этого обобщенного представления, мы проанализировали динамику отдельных симуляций ретрансляции. Мы классифицируем каждый цикл как приводящий к критическому сбою, если он привел к падению оценки не менее чем на 10 %. В таблице 9 приведены итоги анализа, в которых для каждой модели указана вероятность критической ошибки после N взаимодействий, а также доля общей потери качества, приходящаяся на критические ошибки. Мы обнаружили, что модели не выходят из строя из-за «смерти от тысячи порезов» (т. е. множества мелких ошибок). Напротив, в некоторых раундах они обеспечивают почти идеальную реконструкцию, а в нескольких раундах терпят критические сбои, теряя, как правило, 10–30 и более баллов за один цикл. Эти редкие критические сбои объясняют около 80% общего ухудшения качества документов, которое мы наблюдаем. Более мощные модели не лучше избегают мелких ошибок; они отсрочивают критические сбои и сталкиваются с ними при меньшем количестве взаимодействий.

Удаление против повреждения (Приложение F)

Рисунок 7: Разделение деградации на утрату (отсутствующие элементы) и повреждение (элементы присутствуют, но являются некорректными).

Рисунок 7: Разделение деградации на утрату (отсутствующие элементы) и повреждение (элементы присутствуют, но являются некорректными).

До сих пор в статье в основном рассматривалось общее ухудшение качества, происходящее в ходе симуляции работы с документами. Однако ухудшение качества может быть вызвано несколькими лежащими в основе явлениями. Чтобы более подробно изучить этот вопрос, мы разбиваем ухудшение качества модели на две составляющие: удаление контента и повреждение существующего контента. Для этого анализа мы используем компонент «Статистика доменов» (Domain Statistics) в рамках тестового набора (см. рисунок 5). Для каждого домена мы подсчитываем количество структурированных элементов (например, ингредиентов, этапов) до и после полного цикла: любое уменьшение количества приписывается удалению, а оставшееся ухудшение — повреждению. Результаты анализа для каждой модели представлены на рисунке 7. Мы обнаружили, что ухудшение более слабых моделей происходит в основном из-за удаления контента, в то время как ухудшение передовых моделей связано с повреждением контента.

Характеристики документов (Приложение G)

Рисунок 8: Величина эффекта d по Коэну для влияния характеристик документов на результаты

Рисунок 8: Величина эффекта d по Коэну для влияния характеристик документов на результаты

Мы проанализировали, как различные характеристики документов влияют на производительность модели, и обнаружили, что модели работают лучше в программных областях (Python, DBSchema) по сравнению с областями естественного языка (например, Recipe, Fiction). Производительность также выше в областях с высокой повторяемостью и структурной плотностью (например, Molecule, Chess) и ниже в областях с богатым неповторяющимся словарным запасом (например, Transit, Textile). Это подтверждает предыдущие выводы о том, что эффективность LLM максимальна в программных или структурированных областях, где можно определить проверяемые вознаграждения (Suma and Dauncey, 2025). С этой точки зрения нашу работу можно интерпретировать как процесс создания проверяемых вознаграждений для широкого спектра областей путем построения специфичного для каждой области синтаксического анализа и оценки.

Семантические операции (Приложение H)

Рисунок 9: Сложность операции: бисериальная корреляция с оценкой реконструкции (GPT 5.2)

Рисунок 9: Сложность операции: бисериальная корреляция с оценкой реконструкции (GPT 5.2)

Каждая задача редактирования в DELEGATE-52 была помечена тегами семантических операций, которые отражают действия, которые модель должна выполнить для успешного выполнения задачи (такие как сортировка, слияние или манипуляции со строками). 11 семантических операций перечислены на рисунке 9, а также приведены результаты анализа точечно-бисериальной корреляции между наличием тега и оценкой реконструкции GPT 5.2 за один цикл взаимодействия. Мы обнаружили, что задачи редактирования, требующие глобальной реструктуризации документа (например, разделение и слияние, классификация), значительно сложнее, чем задачи, включающие локальные операции (например, манипуляции со строками, ссылки). В Приложении H мы также показываем, что задачи, требующие координации нескольких операций, являются более сложными, чем задачи, включающие только одну операцию.

6. Выводы

Выводы для разработчиков LLM

В данной работе мы используем DELEGATE-52 в первую очередь в качестве инструмента оценки для понимания возможностей современных LLM. Разработанные нами рабочие среды можно адаптировать для обучения моделей, при этом потенциальной основой для обучения может служить литература по обучению с обеспечением циклической согласованности (Zhu et al., 2017). Каждый из 52 доменов можно рассматривать как «мини-тренажерный зал» для онлайн-обучения с подкреплением — среду моделирования, в которой агент (LLM) может быть обучен выполнять циклы задач без потерь. Требуется тщательная разработка системы вознаграждений, чтобы избежать обучения агентов некорректному поведению (т. е. «хакингу» вознаграждений (Skalse et al., 2022)), например, выполнению операции no-op (т. е. нередактированию документа) или объединению копий исходного ввода для облегчения реконструкции. Короче говоря, сочетание вознаграждений, которые одновременно учитывают как следование инструкциям, так и сохранение контента, может стать многообещающим направлением для использования DELEGATE-52 при обучении моделей в различных областях, где отсутствуют эталонные решения.

Выводы для специалистов в области НЛП

Наши эксперименты с моделированием указывают на несколько недостаточно исследованных направлений, заслуживающих большего внимания со стороны сообщества, которые мы кратко изложим ниже. Во-первых, эффективность модели при коротких взаимодействиях не всегда позволяет предсказать её эффективность в долгосрочной перспективе, и изучение возможностей модели при длительных взаимодействиях (помимо управления памятью) имеет решающее значение для понимания её готовности к реалистичным рабочим процессам с делегированием задач: нам требуется больше бенчмарков, ориентированных на долгосрочную перспективу. Во-вторых, усилия по пониманию возможностей моделей распределены неравномерно по различным областям, причем непропорционально много внимания уделяется математическим и программным возможностям. Между тем значительная часть интеллектуальной работы происходит в других областях: нам нужны более широкие бенчмарки для устранения этого разрыва, изучающие возможности в различных профессиях и областях. В-третьих, сообщество иногда рассматривает «бенчмарки агентов» и «бенчмарки LLM» как отдельные области, но их следует рассматривать как два режима работы для выполнения задач: при тестировании LLM нам необходимо учитывать различные режимы работы LLM, чтобы лучше понять его возможности и ограничения.

Выводы для пользователей систем с ИИ

Делегируя работу системам ИИ, пользователи должны проявлять осторожность и не обобщать возможности LLM в одной области на другие области. Возможности моделей характеризуются неравномерным распределением (Dell’Acqua et al., 2023): модели демонстрируют высокую (и порой неожиданную) эффективность при решении определённых задач, но допускают серьёзные ошибки при решении других. Современные LLM готовы к делегированию рабочих процессов в некоторых областях, таких как программирование на Python, но не в других, менее распространенных областях. В целом пользователям по-прежнему необходимо внимательно следить за работой ИИ-систем, когда они выполняют задачи от их имени. Наши эксперименты указывают на обнадеживающую тенденцию, например, если посмотреть на семейство GPT: между моделями GPT 4o и GPT 5.4, которые мы тестировали, прошло 16 месяцев, но производительность по тестам выросла с 14,7% до 71,5%, что свидетельствует о быстром прогрессе.

7. Связанные работы

Наша работа находится на стыке четырёх научных направлений.

Оценка систем искусственного интеллекта для интеллектуального труда.

ИИ-системы всё чаще находят применение в профессиях, связанных с интеллектуальным трудом: согласно данным Бика и др. (2024), в конце 2024 года около 40 % американцев трудоспособного возраста использовали генеративный ИИ на работе, а опросы показывают, что специалисты в сфере интеллектуального труда активно интегрируют большие языковые модели в свои рабочие процессы (Брахман и др., 2024; Ulloa и др., 2025). Однако было показано, что существующие бенчмарки не соответствуют реальным условиям использования (Wang и др., 2026).

Сообщество усердно работает над созданием тестов, которые лучше отражают реальную работу, разрабатывая отраслевые бенчмарки для обслуживания клиентов (Huang et al., 2024; Yao et al., 2024), интеллектуальной работы в предприятиях (Drouin et al., 2024; Xu et al., 2024), ИТ-операций (Jha et al., 2025) или охватывающие несколько профессий (Chen et al., 2025a; Patwardhan et al., 2025; Mazeika et al., 2025). Однако такие тестовые наборы требуют дорогостоящего аннотирования экспертами, что часто ограничивает их охват.

В рамках другого направления исследований проводился анализ взаимодействий, зафиксированных в журналах, например, пользователей ChatGPT от OpenAI (Chatterji et al., 2025), Claude от Anthropic (Handa et al., 2025) или Bing Copilot от Microsoft (Tomlinson et al., 2025). Затем исследователи могут сопоставить эти взаимодействия с таксономиями рабочих задач, такими как O*NET (Peterson et al., 2001), получая представление о современных методах работы. Однако такие исследования требуют осторожного обращения с конфиденциальными данными и ограничены несколькими организациями, имеющими доступ к журналам взаимодействий в больших объемах.

Сравнительный анализ систем ИИ для редактирования документов

Редактирование документов является одной из наиболее распространенных задач в интеллектуальной работе (Siu and Fok, 2025) и одним из основных вариантов использования систем на основе LLM (Handa et al., 2025; Eloundou et al., 2023). Это стимулировало активность исследовательских сообществ, изучающих возможности систем ИИ в данной области.

Устоявшееся сообщество разработало методологии для изучения редактирования кода, создав такие наборы для оценки, как CanItEdit (Cassano et al., 2023), SWE-bench (Jimenez et al., 2023), CodeEditorBench (Guo et al., 2024) и SWE-Refactor (Xu et al., 2026).

Для непрограммных областей, где оценка не может опираться на проверяемое выполнение, были предложены более целенаправленные бенчмарки, например, для оценки возможностей редактирования новостных статей (Spangher et al., 2022), упрощения текста (Laban et al., 2023), творческого написания художественной литературы (Chakrabarty et al., 2024) или выполнения инструкций (Raheja et al., 2023; Dwivedi-Yu et al., 2022). Что касается структурированных текстовых доменов, в предыдущих работах рассматривались редактирование графических файлов (SVGEditBench (Nishina and Matsui, 2024), SVGenius (Chen et al., 2025b)), диаграмм и таблиц (ChartEditBench (Kapadnis et al., 2026), WikiTableEdit (Li et al., 2024), ChartE3 (Li et al., 2026)), наборов слайдов (PPTArena (Ofengenden et al., 2025), DECKBench (Jang et al., 2026)) или генерации структурированного вывода в различных форматах (Yang et al., 2025).

Эти предыдущие работы, как правило, сосредоточены на одной области, для которой подбирается специальная оценка. С помощью DELEGATE-52 мы используем более обобщаемый подход, который позволяет нам расширить нашу методологию до 52 областей: мы разрабатываем программные парсеры для каждой области и используем оценку на основе обратного перевода, которая позволяет обойтись без справочных материалов.

Обратный перевод

Обратный перевод (также известный как «перевод по кругу») берет своё начало в сообществе нейронного машинного перевода (NMT); ранние исследования показали, что перевод по кругу на моноязычных корпусах можно эффективно использовать для расширения набора данных и повышения качества перевода (Sennrich et al., 2015; Lample et al., 2017). Помимо расширения набора данных, обратный перевод использовался в качестве прямого обучающего сигнала в рамках двойного обучения, где прямые и обратные модели совместно оптимизируются посредством обеспечения согласованности в обоих направлениях (He et al., 2016; Hoang et al., 2018), а также в качестве метода оценки без использования эталонного текста, где точность перевода в обоих направлениях служит индикатором качества перевода (Somers, 2005; Zhuo et al., 2022).

Затем обратный перевод был успешно применен в других областях, например, в области кода, где он использовался для обучения (unsupervised) моделей перевода кода между языками программирования (Lachaux et al., 2020; Rozière, 2021, Leveraging AU), а также для совместного обучения генерации кода и суммаризации в качестве двойных задач (Wei et al., 2019). Совсем недавно обратный перевод был применен к выполнению инструкций для улучшения согласованности LLM (Li et al., 2023; Nguyen et al., 2024).

В ряде работ рассматривается возможность объединения последовательных циклов обратного перевода в качестве метода оценки согласованности или устойчивости моделей, позволяющего определить, сохраняют ли они информацию при последовательном применении обратимых преобразований (Hong et al., 2025; Min et al., 2023; Allamanis et al., 2024; Maveli et al., 2026).

Мы расширяем подход «обратный перевод как оценка» (Zhuo et al., 2022; Allamanis et al., 2024) с однократных циклов в отдельных областях до цепочек последовательностей по 52 различным профессиям, моделируя длинные делегированные рабочие процессы, в которых ошибки накапливаются. Это сводит оценку к измерению семантической эквивалентности с исходным документом, позволяя нам масштабировать оценку по различным областям без необходимости аннотирования.

Оценка длительного взаимодействия, охватывающего несколько сеансов

Системы искусственного интеллекта чаще всего оцениваются на основе отдельных диалогов (одиночных сеансов) без учета предшествующей истории или контекста. Xu и др. (2021) представили первый бенчмарк по многосеансовым диалогам, продемонстрировав, что модели, обученные на одиночных сеансах, не способны поддерживать связный долгосрочный диалог, а Jang и др. (2023) расширили этот набор до 1 млн диалогов с разнообразной временной динамикой.

С тех пор сообщество разработало тестовые наборы для оценки памяти в LLM на протяжении сеансов. Maharana et al. (2024) оценили очень долгосрочную память в диалогах, а Wu et al. (2024) предложили LongMemEval, тест для оценки основных способностей памяти (запоминание, извлечение, синтез) в чат-помощниках, который был расширен более поздними тестами, такими как EverMemBench (Hu и др., 2026) и LifeBench (Cheng и др., 2026), проверяющими память в сотнях взаимодействий и с использованием разнообразных источников информации.

Помимо памяти, в других работах изучалась персонализация LLM в рамках нескольких сеансов: Jiang и др. (2025) провели сравнительный анализ динамического профилирования пользователей на основе более 60 сеансов, Li и др. (2025) исследовали вывод неявных предпочтений, а Mehri и др. (2026) оценили, как агенты со временем усваивают предпочтения, связанные с совместной работой. В недавних работах оценка на основе нескольких сессий была также расширена на агентные системы: Zheng et al. (2025) провели тестирование непрерывного обучения у агентов LLM, He et al. (2026) проверили память в взаимозависимых задачах с несколькими сессиями, а Du et al. (2025) представили первый бенчмарк для диалогов, ориентированных на задачи с несколькими сессиями.

В предыдущих работах многосессионное взаимодействие рассматривается в основном как проблема памяти: может ли система запоминать, извлекать или адаптироваться на основе прошлых взаимодействий? С помощью DELEGATE-52 мы изучаем ортогональный и малоизученный режим сбоя: ухудшает ли повторяющееся взаимодействие с LLM качество создаваемых артефактов. Мы изучаем, как ошибки модели в ранних сессиях накапливаются и влияют на производительность в долгосрочной перспективе.

8. Ограничения

Взаимодействие в рамках одного запроса.

В наших симуляциях используются сеансы, состоящие из одного раунда, в которых каждая инструкция полностью определяет задачу без необходимости уточнений. На практике пользователи дают неполные инструкции и постепенно уточняют свои намерения в ходе многораундового диалога (Herlihy et al., 2024; Kim et al., 2026), при этом эффективность LLM значительно снижается в условиях многораундового взаимодействия (Laban et al., 2025). Расширение DELEGATE-52 до многораундовых и многосессионных симуляций (например, посредством фрагментации инструкций или симуляции пользователей (Naous et al., 2025)) вероятно усугубило бы это снижение эффективности.

Практические ограничения.

Наши параметры симуляции — размер документа (3–5 тыс. токенов), контекст отвлекающих элементов (8–12 тыс. токенов), длина ретрансляции (20 взаимодействий) — были выбраны с учетом практических затрат и ограничений контекстного окна и занижают реальные масштабы. Эксперименты показывают, что увеличение этих параметров усугубляет снижение производительности.

Концептуальные ограничения.

Наша методология основана на (1) обратном переводе и (2) доменно-специфическом синтаксическом разборе для оценки без использования справочных материалов, что накладывает ограничения в трёх аспектах:

  • задачи ограничиваются редактированием документов (исключая другие виды интеллектуальной деятельности, такие как коммуникация или планирование);

  • правки должны быть обратимыми (см. Приложение B.3);

  • а при оценке предпочтение отдаётся структурированным доменам, где синтаксический разбор является выполнимым.

Мы исследуем возможность расширения нашей методологии на более открытые задачи генерации путем включения домена «Художественная литература» в качестве одного из доменов в тестовом наборе, хотя это требует адаптации оценки с использованием специализированного метода оценки (Chakrabarty et al., 2025), предназначенного для творческого письма.

9. Заключение

В данной работе мы провели масштабное моделирование того, как пользователи могут делегировать задачи большим языковым моделям (LLM) в 52 профессиональных областях. Мы обнаружили, что современные LLM являются ненадежными исполнителями: даже передовые модели искажают в среднем 25 % содержания документов в ходе длительных рабочих процессов, причем редкие, но серьезные ошибки незаметно накапливаются с течением времени. Наш анализ показывает, что ухудшение качества усиливается с увеличением длины документа, горизонта взаимодействия и наличия отвлекающих факторов, и не смягчается использованием инструментов, позволяющих управлять моделью. Эти результаты подчеркивают фундаментальный пробел в надежности, который подрывает доверие к делегированию. Мы выпускаем DELEGATE-52 в качестве общедоступного инструмента для мониторинга готовности систем ИИ к выполнению делегированных задач в профессиях, связанных с интеллектуальным трудом.

Это перевод научной статьи от исследователей компании Microsoft. Статья была опубликована 17 апреля 2026 года. См. источник