TL;DR
Когда просишь LLM многократно улучшать один и тот же текст или документ, качество не растёт, а падает. Причём не потому что модель «не старается» — а потому что каждая итерация без ограничений даёт ей свободу переписать то, что уже работало. Модель начинает «исправлять» по своим внутренним правилам, а не по твоим. Это исследование это доказывает строго: метрика упала с 0.792 до 0.772 после 8 итераций. 44% всего ухудшения произошло уже после первой итерации.
Главная находка: проблема не в том, что модель критикует неправильно — она и без конкретной критики ломает результат. В контрольном эксперименте убрали всю обратную связь от судьи, оставили только инструкцию «улучши» — деградация осталась той же. Это значит, что корень проблемы в неограниченной регенерации: без явного запрета что-то менять, модель будет менять.
Решение простое: добавить в промпт на ревизию инструкцию сохранения структуры — явно запретить изменять то, для чего нет чёткого основания. Это снизило долю катастрофических потерь (падение качества на >10%) с 3.6% до 0.8%. Работает в обычном чате, никакого кода не нужно.
Схема метода
БЕЗ ЗАЩИТЫ (как делают сейчас):
Запрос → «Улучши это» → Итерация 1 → «Улучши ещё» → Итерация 2 → ...
Результат: модель ушла от оригинала, "починила" то, что не было сломано
С ЗАЩИТОЙ (как надо):
Запрос → «Улучши это. [Инструкция замка]» → Итерация 1 → «Улучши ещё. [Инструкция замка]» → ...
Результат: изменяется только то, для чего есть явное основание
Всё в одном промпте — добавляешь инструкцию замка к каждому запросу на ревизию.
Пример применения
Задача: Ты пишешь питч для инвесторов для своей SaaS-компании в B2B. Попросил Claude сделать первую версию — вышло хорошо. Теперь хочешь итерировать: «сделай сильнее», «добавь конкретики», «переработай».
Промпт с защитой:
Вот питч для инвесторов. Улучши его: сделай аргументы острее, добавь
конкретики там, где её не хватает.
[вставить питч]
ВАЖНО при редактировании:
— Сохраняй существующую структуру и последовательность разделов
— Не меняй формулировки, которые уже работают хорошо
— Изменяй только то, для чего есть явное основание из моей задачи
— Не трогай цифры, если я не давал новых данных
— Если что-то кажется тебе «неправильным», но прямого указания менять нет — оставь как есть
Результат: Модель улучшит конкретные части по твоей задаче, но не начнёт переписывать структуру, менять тон, «исправлять» цифры или переставлять разделы «для лучшего флоу» — что обычно и происходит при открытом «улучши».
Почему это работает
Слабость LLM: Когда ты говоришь «улучши», модель не знает, что именно защищать. Она видит текст с потенциальными улучшениями везде — и начинает их вносить. У неё есть собственные «конвенции» (правила о том, как должен выглядеть хороший текст), и она натягивает текст на них. Это не баг — это нормальная работа модели без ограничений.
Почему это незаметно: Результат после первой итерации часто кажется лучше. Модель действительно что-то улучшила. Но она также изменила то, что не просили менять. После второй итерации — ещё немного. К пятой — текст уже мало похож на оригинал, и вернуться к тому, что работало, почти невозможно.
Как инструкция замка исправляет это: Явный запрет «не трогай без основания» даёт модели критерий отбора изменений. Без этого критерия любое изменение кажется ей допустимым. С ним — модель фильтрует: «есть ли у меня явная задача на этот фрагмент?» Это сужает зону изменений до того, что действительно нужно.
Рычаги управления: - Жёсткость замка → чем строже формулировка запрета («не изменяй ничего, кроме...»), тем консервативнее правки — хорошо для финальных итераций - Список исключений → можно явно указать что менять нельзя: «не трогай первый абзац, название, цифры» - Инверсия → вместо «что нельзя» — «что можно»: «меняй только формулировки предложений, не трогай структуру»
Шаблон промпта
{задача по улучшению} следующий текст:
{текст}
При редактировании соблюдай ограничения:
— Сохраняй существующую структуру и порядок элементов
— Не изменяй то, что прямо не указано в задаче
— Если видишь потенциальное улучшение вне задачи — не вноси его
— Изменяй только при наличии явного основания из запроса выше
— Что менять нельзя точно: {список защищённых элементов}
Что подставлять:
- {задача по улучшению} — конкретная задача: «Сделай более убедительным», «Добавь примеры», «Сократи на 30%»
- {текст} — твой текст, код, структура
- {список защищённых элементов} — опционально: «тон», «цифры», «структура разделов», «первый абзац»
🚀 Быстрый старт — вставь в чат:
Вот шаблон промпта с инструкцией защиты при итеративной правке.
Адаптируй под мою задачу: {твоя задача — что и как хочешь улучшить}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит что ты редактируешь, какова задача правки и что нужно защитить от изменений — потому что именно эти детали определяют баланс между улучшением и сохранением.
Ограничения
⚠️ Компромисс «безопасность vs улучшение»: Инструкция замка снижает катастрофические потери, но также снижает количество улучшений. Модель становится консервативнее. Если нужны радикальные правки — ослабляй ограничения.
⚠️ Не работает с открытыми творческими задачами: Если цель — полностью переработать текст или изменить концепцию, инструкция замка мешает. Она для ситуаций, где базовая структура устраивает.
⚠️ Сам выбор «лучшей» версии — ненадёжен: Если попросишь модель оценить несколько своих драфтов и выбрать лучший, она справится лишь немного лучше случайного выбора. Почти во всех конфигурациях разницы между «выбор модели» и «выбор наугад» нет. Умей оценивать сам или задай внешний критерий.
⚠️ Эффект накапливается: Первая итерация выглядит нормально. Проблема нарастает к 3-5 итерации. Если делаешь больше 2-3 правок подряд — инструкция замка становится критичной.
Как исследовали
Исследователи поставили жёсткий эксперимент: 8 итераций авторевизии таблиц из финансовых документов и научных статей. Модель (Gemini Flash) получала изображение таблицы → генерировала HTML → судья-LLM оценивал результат → генератор правил по оценке → и так 8 раз. Ни разу правильный ответ не показывался модели — только изображение.
Интересная деталь дизайна: проверили пять разных конфигураций судьи — от GPT-nano до Claude Opus — и ни одна не смогла стабильно выбирать лучший вариант лучше случайного. Судьи давали одинаковые оценки разным вариантам в 37-49% случаев, и при повторном оценивании тех же пар результат менялся. Это не «слабая модель» — это системная проблема сравнения внутри одной задачи.
Самый чистый эксперимент: убрали всю обратную связь от судьи, оставили только «вот предыдущий результат, улучши» — деградация осталась той же. Это опровергает интуицию «судья даёт плохую обратную связь, вот и ломается». Нет — ломается сам процесс неограниченной регенерации. Противоречит ожиданиям авторов и меняет вывод: чинить нужно не оценку, а инструкцию.
Адаптации и экстраполяции
🔧 Техника: «Дельта-промпт» — явно указывай ЧТО менять, не ЧТО защищать
Инверсия инструкции замка. Вместо «сохраняй всё, кроме...» — «меняй только это»:
Отредактируй текст ниже.
Разрешённые изменения: только {конкретный список — например, «формулировки предложений»}.
Всё остальное — структура, порядок, цифры, ключевые тезисы — не трогай.
{текст}
Это работает острее для финальной полировки, где 95% текста уже устраивает.
🔧 Экстраполяция: применять принцип к любому «агенту-улучшателю»
Тот же принцип работает когда просишь модель играть роль редактора, критика, ментора. Без явного «что защищать» — критик начнёт предлагать структурные изменения, которых ты не просил. Добавь в системный промпт:
Твоя роль: {редактор / критик / ментор}.
Правило: предлагай изменения только в рамках запроса. Если видишь
потенциальное улучшение вне задачи — упомяни отдельно как опцию,
не включай в основные правки.
Ресурсы
«Evaluation Ability Does Not Imply Optimization Utility: LLM-as-a-Judge Signals in Closed-Loop Table Recognition»
Donghwan Kim — Aidentyx Inc., San Jose, CA, USA
Датасеты: FinTabNet (финансовые таблицы, S&P 500), OmniDocBench (академические статьи, учебники, газеты)