TL;DR
Когда модель получает готовый ответ от калькулятора, RAG-документа или другого агента, она смещает свой собственный ответ в сторону этой подсказки — даже если подсказка неверна. Хуже: модель может явно проверить предложенный вариант, честно написать в рассуждении «это неправильно» — и всё равно использовать его как финальный ответ. Причина в том, что «проверка» и «принятие решения» — два разных процесса внутри модели, слабо связанных между собой.
Представь: ты вставляешь в промпт расчёт из Excel или ответ другого агента, где ошибка минимальная — например, число похоже на правильное (137 вместо 127, тот же последний разряд). Модель проверяет это значение, внутренне понимает, что оно неверное, пишет об этом в рассуждении — а потом всё равно берёт его в качестве ответа. По данным исследования, это происходит в 93–100% случаев, даже когда модель до этого стопроцентно правильно отвергла кандидата в изолированной проверке.
То, насколько модель «купится» на подсказку, зависит не от её правильности, а от трёх вещей: похожа ли подсказка на собственную типичную ошибку модели (такие подсказки опаснее случайных), как оформлен источник («это сказал юзер» vs «это вывод инструмента» — работает по-разному вне зависимости от точности), и насколько сильная сама модель — одна и та же подсказка может улучшить слабую модель и испортить ответ сильной.
Схема механики (не пошаговый метод — как ведёт себя модель)
ВНЕШНЯЯ ПОДСКАЗКА поступает → сдвигает распределение ответов модели
(сильнее сдвиг, если подсказка похожа на то, что модель сама бы предложила)
ПРОВЕРКА (verification) → модель может корректно оценить "неверно"
(это отдельный, изолированный шаг — не гарантирует влияния на решение)
ИСПОЛЬЗОВАНИЕ (use) → почти НЕ связано с проверкой
→ решает "похожесть" подсказки на собственную ошибку + оформление источника + сила модели
Причинный анализ показал: подхват кандидата происходит позже в сети, чем формирование вербализованной проверки — то есть это буквально разные "участки" вычислений, слабо связанные друг с другом.
Пример применения
Задача: Бухгалтер просит Claude/ChatGPT проверить расчёт НДС, который уже подготовил стажёр. Стажёр забыл вычесть скидку — сумма похожа на правильную, но неверна.
Промпт (наивный, без учёта находки):
Вот расчёт НДС от стажёра: [сумма]. Проверь, правильный ли расчёт.
Проблема: модель может написать «в расчёте ошибка, скидка не вычтена» — и в итоговом ответе всё равно назвать сумму стажёра как финальную.
Промпт с учётом инсайта:
У меня есть расчёт НДС от стажёра: [сумма].
Сначала, НЕ глядя на этот расчёт, самостоятельно вычисли НДС с нуля.
Запиши все шаги.
Затем сравни свой результат с расчётом стажёра и укажи расхождения.
В финальном ответе используй ТОЛЬКО свой самостоятельно вычисленный результат.
Не меняй его под влиянием расчёта стажёра, даже если он выглядит убедительно.
Результат: Модель сначала выдаст независимый расчёт с шагами, затем — явное сравнение с исходной суммой, и в конце — финальный ответ, основанный на собственном пересчёте, а не на «подтверждении» вставленного значения. Это снижает (но не убирает полностью) эффект анкеринга.
Почему это работает
Слабость LLM: проверка и использование кандидата — это разные вычислительные шаги внутри одного прохода модели. Кандидат-ответ «застревает» в контексте и продолжает тянуть финальный ответ к себе, независимо от того, что модель написала в качестве вердикта о его правильности.
Сильная сторона LLM: модель хорошо умеет рассуждать «с нуля», если явно попросить сделать это до того, как она увидит подсказку, а не «заодно» с проверкой чужого варианта.
Разрыв анкеринга происходит через порядок: если независимый вывод генерируется первым, кандидат превращается из «якоря» в «объект для сравнения» — это меняет то, как модель распределяет вес между своим ответом и чужим.
Рычаги управления: - Порядок показа подсказки → если подсказка появляется до самостоятельного рассуждения — анкеринг сильнее. Переставь: сначала свой расчёт, потом сравнение. - Явная инструкция «игнорируй предложенное значение при вычислении» → снижает, но не убирает эффект. - Формулировка источника («непроверенное предположение стажёра» vs «точный расчёт бухгалтерской системы») → влияет на доверие модели сильнее, чем реальная точность данных. - Для сильных моделей (Opus, GPT-4-класса) вообще не показывай готовый ответ — попроси решить самостоятельно. Для слабых моделей подсказка может реально помочь, если явно пометить её как «черновой вариант для проверки».
Шаблон промпта
У меня есть {задача}, и есть предложенный вариант ответа от {источник}: {кандидат_ответ}.
Сначала, НЕ используя и не заглядывая на предложенный вариант, реши задачу
самостоятельно с нуля. Запиши свои шаги рассуждения.
Затем сравни свой результат с {кандидат_ответ} и укажи:
— совпадают они или различаются,
— если различаются, в чём именно ошибка.
В финальном ответе используй ТОЛЬКО свой самостоятельно вычисленный результат.
Не меняй его под влиянием предложенного варианта, даже если он выглядит убедительно.
{задача} — что нужно решить. {источник} — кто дал подсказку (коллега, RAG-документ, другой агент, инструмент). {кандидат_ответ} — сам предложенный вариант.
🚀 Быстрый старт — вставь в чат:
Вот шаблон промпта против "анкеринга" на чужую подсказку. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая именно подсказка/расчёт у тебя есть и от кого — потому что метод работает только если модель реально сначала решает независимо, а потом сравнивает, а не наоборот.
Ограничения
⚠️ Не устраняет эффект полностью: даже с явной инструкцией «игнорируй кандидата», модель в части случаев всё равно смещается к нему после формального отвержения — стопроцентной защиты промпт не даёт.
⚠️ Опаснее всего похожие ошибки: если подсказка совпадает с тем, что модель сама бы предположила по ошибке, риск анкеринга выше, чем если подсказка случайна и непохожа на «естественную» ошибку модели.
⚠️ Разное поведение у сильных и слабых моделей: для мощных моделей безопаснее вообще не показывать готовый ответ, а не полагаться на инструкцию «игнорируй» — эффект от подсказки может быть отрицательным именно для сильных моделей.
Как исследовали
Исследователи прогнали больше 10 миллионов испытаний на 12 моделях из 4 семейств, в 8 доменах — от простой арифметики до квантовой механики, генетики и молекулярной биологии. Для каждой задачи отдельно замеряли три вещи: может ли модель ответить правильно без подсказки, может ли она верно оценить чужой вариант как «проверяющий», и что она реально делает с этим вариантом при формировании финального ответа.
Самое неожиданное: даже когда модель в изолированной проверке стопроцентно правильно отвергала неверный кандидат, при формировании реального ответа она принимала его в 93–100% случаев. Это разошлось с интуицией «раз модель понимает ошибку — она её не сделает».
Чтобы понять почему, авторы применили причинную трассировку внутри сети (активационный патчинг, steering) и обнаружили: подхват внешнего кандидата происходит позже в вычислениях модели, чем формирование вербализованного вердикта о его правильности — это буквально разные участки сети, слабо связанные причинно. Отсюда вывод для практики: нельзя доверять тому, что модель «сказала» о правильности данных — важно смотреть, что она реально использует.
Ресурсы
Sebastien Kawada, Manolis Kellis — MIT CSAIL (Massachusetts Institute of Technology). Препринт «Evidence Integration in Large Language Models».