TL;DR
Когда вы просите LLM поправить один пункт в документе — план, смету, конфиг — модель часто чинит только то, что вы явно назвали, и забывает пересчитать всё, что от этого зависит. Исследование проверяет именно эту способность: находить скрытые зависимости и тащить правку по цепочке, когда информация о связях лежит не в самом документе, а в переписке, которая привела к его созданию.
Главная находка: модели теряют связи, потому что смотрят в основном на финальный документ, а логика «почему тут стоит именно это число» была озвучена раньше в разговоре и не зафиксирована явно. Например, бюджет считался как «200$ × 3 человека» — но в итоговом плане осталась только цифра, без формулы. Убираешь один пункт — бюджет не пересчитывается, потому что модель не помнит, откуда он взялся. Ошибка почти всегда одна и та же: модель правит слишком мало, а не слишком много.
Метод борьбы с этим — не разовый трюк, а комбинация двух приёмов: (1) всегда давать модели одновременно и финальную версию документа, и полную историю разговора — по отдельности каждое из них хуже; (2) попросить модель сгенерировать 3-5 независимых вариантов правки и затем выбрать лучший — либо силами самой модели, либо взяв «самый типичный» вариант.
Схема метода
ШАГ 1: Подать модели финальный документ + всю историю переписки (не по отдельности!)
→ запрос на правку
ШАГ 2: Сгенерировать 3-5 независимых версий правки (отдельные запросы или "дай мне N вариантов")
ШАГ 3: Показать модели все варианты → попросить выбрать самый полный/правильный
→ финальный ответ
Шаг 1 — обязательный минимум. Шаги 2-3 — усиление для важных/сложных правок, требует нескольких запросов подряд.
Пример применения
Задача: Вы несколько сообщений обсуждали с ChatGPT ремонт квартиры — комнаты, материалы, бюджет считался как «примерно 3000₽ за м² × площадь». В итоге получили финальный план с бюджетом. Теперь просите: «Убери ремонт балкона из плана».
Промпт:
Вот вся наша переписка про ремонт (вставляю целиком):
{история диалога}
Вот текущий финальный план:
{документ}
Правка: убери ремонт балкона из плана.
Проверь, какие ещё пункты зависят от этого изменения (бюджет, сроки, список материалов)
и обнови их тоже. Перечисли явно, что ты изменил и почему.
Результат: Модель уберёт балкон из списка, а благодаря присутствию истории — увидит, что бюджет считался по формуле «цена за м²», и пересчитает итоговую смету и сроки. Без истории (только план) модель скорее всего забудет про бюджет.
Для критичных документов — попросите три раза с разными формулировками «пересчитай план после удаления балкона», сравните три ответа и выберите тот, где учтены все пункты (бюджет, сроки, материалы).
Почему это работает
LLM плохо держит в голове связи между элементами, если они не написаны явно рядом. Финальный документ — это «результат», а формула, которая его породила («бюджет = цена × людей»), была сказана раньше и потерялась. Модель видит цифру, но не видит её происхождение.
Зато LLM хорошо справляется с сравнением готовых вариантов — заметить, какой из трёх кандидатов полнее учёл зависимости, ей проще, чем сгенерировать идеальный ответ с первого раза без единого прохода.
Метод соединяет эти два факта: даём модели весь контекст (история + документ), чтобы минимизировать потерю связей, а затем просим несколько попыток и выбор — чтобы поймать хотя бы в одном варианте то, что могло проскользнуть в другом.
Рычаги управления: - Число вариантов (3-5) → для простых правок хватит 2-3, для длинных документов с кучей зависимостей — больше - Способ выбора: «сама модель выбирает лучший» ловит больше пропущенных правок; «выбрать самый типичный вариант» (сравнить все между собой и взять похожий на большинство) даёт меньше лишних правок, но чуть хуже ловит редкие зависимости - Явная фраза «проверь, что ещё зависит от этого изменения» в промпте — усиливает эффект даже без множественных попыток
Шаблон промпта
Вот вся история нашего диалога по задаче {название задачи}:
{история переписки}
Вот текущая финальная версия документа:
{документ}
Правка: {что нужно изменить}
Перед тем как ответить:
1. Найди все элементы документа, которые логически зависят от этого изменения
(суммы, даты, количества, ссылки на изменяемый пункт).
2. Обнови их вместе с основным изменением.
3. Явно перечисли, что ты изменил и почему — не только то, что я попросил напрямую.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для правки документа с учётом скрытых зависимостей.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая у вас история переписки и что именно нужно поправить — потому что без полного контекста она не сможет восстановить скрытые зависимости, а метод работает именно на этом.
Ограничения
⚠️ Не даёт 100% точности: даже лучшие модели с лучшим методом ошибаются в среднем в 5-30% случаев — метод снижает риск, но не убирает его.
⚠️ Строгий консенсус вредит: если просить модель принимать правку только тогда, когда все варианты сошлись — точность падает сильно (на 13-21%), потому что правильные, но редко замеченные правки отбрасываются.
⚠️ Большие документы — слабое место: чем больше элементов в документе, тем больше пропущенных зависимостей у всех моделей без исключения.
⚠️ Множественные попытки стоят времени: генерация 3-5 вариантов и выбор — это несколько запросов подряд, а не один быстрый ответ.
Как исследовали
Исследователи из NTT собрали бенчмарк RevPropBench: 150 примеров в 9 практических сферах — туристические планы, счета, списки покупок, расписания проектов, курсы, конфиги ПО и другие. Сначала сильная модель (GPT-5.5) генерировала диалог и финальный JSON-документ, потом добавлялся запрос на правку, а «правильный» ответ размечали люди с помощью Claude Opus как ассистента.
На этом бенчмарке проверили шесть моделей (от небольших gpt-oss-20b до gpt-5.4-mini и разных версий qwen3.5) девятью способами — от простого одного прохода до сложных схем с несколькими попытками и выбором. Одиночный проход дал точность 68-93% в зависимости от модели — большой разброс. Самое интересное: добавление истории разговора к документу давало прирост стабильно во всех моделях — подтверждает, что зависимости прячутся именно в переписке, не в самом документе. А среди способов усиления самым выгодным по соотношению «затраты/эффект» оказался выбор лучшего из трёх параллельных вариантов — либо силами модели, либо через «самый типичный» кандидат.
Ресурсы
RevPropBench, Daisuke Kikuta, NTT, Inc. Код и датасет: github.com/ntt-dkiku/llm-revision-propagation