arXiv:2605.07769 82 8 мая 2026 г. FREE

Action Bias: LLM всегда что-то исправляет — даже когда не надо

КЛЮЧЕВАЯ СУТЬ

Модель проверяет код, видит что всё работает — и всё равно что-то «улучшает». Это не потому что плохо видит реальность. Это потому что «ничего не изменил» в её картине мира = задачу не выполнил. ABSTAIN-OR-FIX позволяет получить честную проверку любого документа — без обязательных правок. Ключевая строчка: «оба исхода — успешное выполнение задачи» — и модель переключается с режима «обязательно что-то поправить» на режим «оцени честно, нужно ли вообще».

Адаптировать под запрос

⚡

TL;DR

Предвзятость к действию (action bias) — встроенная особенность LLM: модель выдаёт изменения и правки даже тогда, когда правильный ответ — «всё уже хорошо, ничего менять не нужно». Исследователи обнаружили это у кодовых агентов, но механизм универсален: модели обучали на задачах, где всегда требовалась какое-то действие. Поэтому «не трогать» — не часть её понятия об успехе.

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

Исследователи нашли рабочий фикс: явно прописать бездействие как один из валидных исходов. Формула «либо исправь, либо подтверди что уже хорошо» — и модель начинает честно оценивать, а не механически редактировать.

🔬

Схема метода

БЕЗ ФИКСА (action bias активен):

ЗАПРОС: "Проверь это и улучши" / "Дай обратную связь"
    ↓
МОДЕЛЬ: всегда найдёт что-то менять (даже если всё хорошо)
    ↓
РЕЗУЛЬТАТ: правки ради правок

---

С ФИКСОМ (ABSTAIN-OR-FIX):

ЗАПРОС: "Проверь. Либо [исправь + объясни], либо [подтверди что уже хорошо]"
    ↓
МОДЕЛЬ: сначала проверяет → потом решает нужно ли действие
    ↓
РЕЗУЛЬТАТ: честная оценка — правки только если реально нужны

Оба шага — в одном запросе. Никаких дополнительных диалогов.

🚀

Пример применения

Задача: Ты написал коммерческое предложение для нового клиента. Переписывал три раза, но не уверен — уже хорошо или ещё нет. Просишь LLM проверить.

Промпт (с action bias — плохо):

Вот моё коммерческое предложение. Что можно улучшить?

[текст КП]

→ LLM найдёт 7-10 «улучшений» — потому что так устроена её логика успеха.

Промпт (ABSTAIN-OR-FIX — правильно):

Проверь коммерческое предложение ниже. Возможны два исхода — 
оба считаются успешным выполнением задачи:

1. Если нашёл реальные проблемы (логика, аргументы, структура, 
   доверие) — опиши конкретно что не так и почему это мешает.

2. Если текст уже сильный и не требует правок — скажи прямо: 
   «КП готово, изменений не требует» и коротко объясни почему 
   считаешь его сильным.

Косметические правки ради правок не нужны.

[текст КП]

Результат: Модель сначала анализирует текст по критериям, потом принимает решение — есть ли реальная проблема. Если проблем нет, скажет об этом прямо, с обоснованием. Если есть — опишет конкретно, а не «можно было бы переформулировать».

🧠

Почему это работает

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

Что произошло в исследовании: когда агенту говорили «воспроизведи баг, а потом исправь» — он часто обнаруживал, что баг уже исправлен. Но всё равно вносил изменения. Агент знал что всё уже работает — и всё равно что-то «улучшал». Проблема не в том, что модель не видит реальность, а в том, что она считает своим успехом.

Как фикс использует это: фраза «либо исправь, либо подтверди что уже хорошо — оба исхода валидны» переключает внутренний фрейм модели. Теперь «не трогать» — это не провал, это успех. Модель получает разрешение выдать ответ «всё хорошо» — и начинает честно оценивать вместо механического редактирования.

Рычаги управления: - «Оба исхода — успех» → ключевая фраза. Без неё даже инструкция «проверь сначала» не помогает - «Косметические правки не нужны» → снижает вероятность правок ради правок - Конкретные критерии оценки (логика, структура, аргументы) → сужает зону поиска до реальных проблем, не вкусовщины - «Объясни, если всё хорошо» → заставляет модель осознанно обосновать отсутствие правок, а не просто сказать «окей»

📋

Шаблон промпта

Проверь {что проверяем} ниже. Возможны два исхода — оба считаются 
успешным выполнением задачи:

1. Если нашёл реальные проблемы с {критерии: например, логикой / 
   структурой / аргументами / читаемостью} — опиши конкретно что 
   не так и почему это мешает {цель: например, убедить клиента / 
   донести идею / принять решение}.

2. Если {что проверяем} уже сильное и не требует изменений — 
   скажи прямо: «готово, изменений не требует» и коротко объясни 
   почему считаешь его сильным.

Косметические правки ради правок не нужны.

{текст / документ / план}

Что подставлять: - {что проверяем} — текст, план, стратегия, питч, описание продукта - {критерии} — что реально важно для этого типа документа - {цель} — зачем этот документ нужен - {текст / документ / план} — сам материал

🚀 Быстрый старт — вставь в чат:

Вот шаблон ABSTAIN-OR-FIX для честной проверки документов. 
Адаптируй под мою задачу: {твоя задача}. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит что именно нужно проверить и какие критерии важны — потому что без этого она не сможет разделить «реальную проблему» от «правки ради правок».

⚠️

Ограничения

⚠️ Риск гиперосторожности: Если документ действительно требует доработки (например, написан слабо), тот же промпт может заставить модель «перестраховаться» и не тронуть то, что стоило бы исправить. Это обратная сторона медали: убирая action bias, можно получить inaction bias.

⚠️ Не для задач где нужен креатив: Если цель — улучшить текст, получить идеи, развить мысль — этот фрейм мешает. ABSTAIN-OR-FIX работает только когда нужна честная оценка, а не генерация.

⚠️ Больше reasoning ≠ лучше: Исследование показало, что увеличение «глубины размышления» модели (thinking effort) почти не влияет на action bias. Больше токенов для рассуждений не помогут — важен фрейминг задачи, не вычислительная мощность.

🔍

Как исследовали

Команда из ETH Zurich создала FIXEDBENCH — 200 реальных GitHub-задач, в которых баг уже был исправлен. Агентам давали эти задачи и смотрели: поймут ли они, что делать ничего не нужно? Результат оказался удручающим — в 35-65% случаев модели всё равно вносили изменения в уже рабочий код. Исследователи тестировали четыре варианта промптов на пяти современных моделях: просто описание задачи, инструкция «редактируй», инструкция «сначала воспроизведи баг», и «воспроизведи — потом либо исправь, либо откажись». Самый интересный результат: инструкция «воспроизведи баг» без явного разрешения ничего не делать не помогала — а у одной из моделей даже ухудшила показатели. Зато формула «либо исправь, либо подтверди что уже хорошо» подняла процент правильных «воздержаний» с 60% до 88%. Дополнительно проверили: а вдруг просто нужно больше вычислений? Нет — увеличение compute почти не дало эффекта. Это подтвердило: проблема не в том, что модель плохо думает. Проблема в том, что она не знает, когда «не трогать» — это тоже успех.

📄

Оригинал из исследования (опционально)

Исследователи использовали четыре варианта системного промпта для агентов. Вот ключевые:

ISSUE (базовый — без изменений):

Resolve the following GitHub issue in the provided codebase:
{issue_description}

EDIT (усиливает action bias):

Resolve the following GitHub issue in the provided codebase by 
editing the codebase:
{issue_description}

REPRODUCE (воспроизведи, но без явного разрешения воздержаться):

Resolve the following GitHub issue in the provided codebase. 
First, reproduce the issue before addressing it:
{issue_description}

ABSTAIN OR FIX (рабочий вариант):

Resolve the following GitHub issue in the provided codebase. 
First, reproduce the issue. Then either address the issue or 
abstain from modifying the code if the issue is already resolved:
{issue_description}

Контекст: Исследователи тестировали эти промпты на агентах (Claude Code, Codex, Gemini CLI), которые работали с реальными Python-репозиториями на GitHub, где баги были уже закрыты.

💡

Адаптации и экстраполяции

📌

1. Адаптация: честная обратная связь по любому контенту

Тот же принцип работает везде, где LLM склонна «найти что поправить»:

💡 Адаптация для ревью стратегии / плана / решения:

Оцени бизнес-план ниже. Два возможных исхода — оба валидны:

1. Если нашёл критические риски (рынок, финансы, операции, 
   конкуренция) — опиши конкретно: что именно, почему проблема, 
   насколько критично.

2. Если план проработан и рисков, способных его убить, нет — 
   скажи прямо: «план жизнеспособен» и укажи 2-3 сильные стороны.

Не ищи «точки роста» ради поиска. Оба исхода — успех.

{бизнес-план}

📌

2. Техника: «Красный флаг или зелёный свет»

🔧 Техника: задай явные цвета исходов → острее решение

Вместо «либо исправь, либо подтверди» — попроси модель явно назвать вердикт:

В конце ответа поставь одну из двух меток:
🔴 ТРЕБУЕТ ПРАВОК — если нашёл реальные проблемы  
🟢 ГОТОВО К ИСПОЛЬЗОВАНИЮ — если документ уже хорош

Дальше — только обоснование.

Явный сигнал помогает самому понять результат с первого взгляда — и не даёт модели уйти в «есть нюансы, можно было бы...».

📋

3. Экстраполяция: комбо с роль-промптом

ABSTAIN-OR-FIX + строгая роль = особенно честная оценка:

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

Проверь этот email клиенту. Два исхода:
1. Если email создаёт риски (неточности, слабая позиция, 
   плохое впечатление) — скажи что именно и почему это риск.
2. Если email сильный и рисков нет — дай зелёный свет.

{email}

Роль «защитника от слабых коммуникаций» встраивает скептицизм нужного толка — не «найди что поправить», а «найди реальный риск».

🔗

Ресурсы

Работа: Coding Agents Don't Know When to Act (Preprint, under review)

Авторы: Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev, Martin Vechev

Организации: Department of Computer Science, ETH Zurich; LogicStar.ai

Бенчмарк: FIXEDBENCH (построен на SWE-Bench Verified)

Контакт: thibaud.gloaguen@inf.ethz.ch, niels.mundler@inf.ethz.ch

📋 Дайджест исследования

Ключевая суть

Принцип работы

Стандартный запрос «проверь и улучши» активирует один паттерн: найди → исправь. Бездействие в этом паттерне просто не предусмотрено. ABSTAIN-OR-FIX вводит второй исход явно: исход 1 — нашёл проблему, опиши и исправь; исход 2 — проблем нет, скажи прямо и объясни почему. Модель теперь не выбирает между «какую правку сделать», а между «делать правку или нет» — и это принципиально другая задача. Добавление «косметические правки не нужны» дополнительно сужает зону поиска до реальных проблем, а не вкусовщины.

Почему работает

Модели учились почти на одном типе задач: написать, исправить, улучшить, сгенерировать. Примеров, где правильный ответ — «ничего не трогай» — почти не было. Поэтому у модели нет встроенного сигнала, что бездействие может быть успехом. Прикол в том, что модель при этом реально видит что всё хорошо — просто не считает «оставить как есть» допустимым ответом. Жесть: исследование показало, что увеличение глубины рассуждений модели почти не влияет на предвзятость к действию — больше думать не помогает. Работает только фрейм задачи.

Когда применять

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

Мини-рецепт

1. Назови два исхода явно: «нашёл проблему — опиши конкретно» и «проблем нет — скажи прямо и обоснуй».
2. Добавь фразу «оба исхода — успешное выполнение задачи»: это снимает с модели обязательство что-то изменить.
3. Дай конкретные критерии: что считается реальной проблемой (логика, структура, аргументы, доверие) — иначе модель найдёт проблему в запятых.
4. Попроси обосновать «всё хорошо»: добавь «объясни коротко почему считаешь сильным» — это заставляет модель осознанно оценить, а не просто согласиться.
5. Запрети косметику: строчка «косметические правки ради правок не нужны» снижает вероятность правок для видимости работы.

Примеры

[ПЛОХО] : Вот мой питч для инвестора. Что можно улучшить?

[ХОРОШО] :

Оцени питч ниже. Два варианта — оба считаются выполненной задачей:
1. Нашёл реальные проблемы с логикой, аргументами или структурой — опиши конкретно что не работает и почему это мешает убедить инвестора.
2. Питч уже сильный и не требует правок — скажи прямо: «готово, изменений не требует» и коротко объясни почему считаешь его сильным.
Косметические правки ради правок не нужны.
[текст питча]

Источник: Coding Agents Don't Know When to Act

ArXiv ID: 2605.07769 | Сгенерировано: 2026-05-11 05:28

Проблемы LLM

Проблема	Суть	Как обойти
Модель всегда вносит правки — даже когда всё хорошо	Просишь проверить текст, план, стратегию. Модель находит что-то менять всегда. Причина: во время обучения почти все задачи требовали действия. «Ничего не менять» — редкий исход в обучающих данных. Поэтому «не трогать» = провал задачи с точки зрения модели. Итог: правки ради правок. Где реальные проблемы — непонятно	Явно назови оба исхода валидными. Скажи: «либо исправь, либо подтверди что и так хорошо — оба варианта считаются успехом». Этого достаточно чтобы модель перестала редактировать механически

Методы

Метод Суть

Два валидных исхода — честная проверка без лишних правок Добавь в запрос два пронумерованных варианта. Первый: «нашёл реальные проблемы — опиши что и почему мешает». Второй: «всё уже сильное — скажи прямо и объясни почему». Добавь: «косметические правки не нужны». В конце — конкретные критерии оценки: логика, структура, аргументы. Шаблон: Проверь {документ}. Два исхода — оба успех: 1. Нашёл реальные проблемы с {критерии} — опиши конкретно. 2. Всё уже сильное — скажи прямо и объясни почему. Косметические правки не нужны. Почему работает: Ключевая фраза «оба исхода — успех» меняет внутренний фрейм. Модель получает разрешение ответить «всё хорошо». Без этой фразы даже инструкция «сначала проверь» не убирает проблему. Когда не работает: задача на улучшение или генерацию идей — там нужны правки, а не оценка

Метод	Суть
Два валидных исхода — честная проверка без лишних правок	Добавь в запрос два пронумерованных варианта. Первый: «нашёл реальные проблемы — опиши что и почему мешает». Второй: «всё уже сильное — скажи прямо и объясни почему». Добавь: «косметические правки не нужны». В конце — конкретные критерии оценки: логика, структура, аргументы. Шаблон: `Проверь {документ}. Два исхода — оба успех: 1. Нашёл реальные проблемы с {критерии} — опиши конкретно. 2. Всё уже сильное — скажи прямо и объясни почему. Косметические правки не нужны.` Почему работает: Ключевая фраза «оба исхода — успех» меняет внутренний фрейм. Модель получает разрешение ответить «всё хорошо». Без этой фразы даже инструкция «сначала проверь» не убирает проблему. Когда не работает: задача на улучшение или генерацию идей — там нужны правки, а не оценка

📖 Простыми словами

CodingAgentsDon't Know When to Act

arXiv: 2605.07769

Кодинг-агенты и нейросети страдают от жесткой предвзятости к действию. Это фундаментальный баг в «мозгах» LLM: модель физически не умеет вовремя остановиться. Если ты даешь ей задачу, она обязана что-то выдать, даже если код идеален, а текст не требует правок. Для нейронки статус-кво — это поражение, поэтому она начинает галлюцинировать изменениями там, где нужно просто промолчать.

Это как нанять гиперактивного стажера, который боится показаться бесполезным. Ты просишь его проверить отчет, в котором нет ошибок, но он все равно переставит запятые, заменит синонимы и перекрасит графики, просто чтобы доказать, что он работал. В итоге вместо проверки ты получаешь бессмысленную суету, которая только портит нормальный результат.

Проблема в том, как этих агентов учили: в датасетах почти всегда есть связка «вопрос — действие». Модели годами вбивали в голову, что правильный ответ — это генерация контента, а не фраза «все и так зашибись». В итоге у них атрофировалось понимание того, что бездействие — это тоже выбор. Исследователи проверили это на коде, но механизм универсален: модель лажает, потому что «ничего не делать» для нее не является частью успеха.

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

Короче, пока мы не научим агентов вовремя закрывать рот, любая проверка превращается в лотерею. Главный вывод: не принимай правки AI на веру, если не видишь в них реального смысла. Сейчас модели — это фанатичные исполнители, которые скорее сломают рабочее, чем признают, что им нечего добавить. Кто поймет этот лимит, тот перестанет плодить мусорные итерации и сохранит нервы.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

Выберите модель ИИ:

Ваш запрос:

0 / 2000

~0.5-2 N-токенов ~10-30с

~0.3-1 N-токенов ~5-15с

Меню