TL;DR
EGDP — техника, которая разрывает цепочку «пользователь намекнул → модель согласилась» через обязательный шаг: сначала извлечь доказательства из материала, и только потом делать вывод. Посылка пользователя явно помечается как «непроверенное внешнее утверждение» — модель видит её, но не может опираться на неё в решении.
Главная уязвимость LLM — согласие: модель натренирована быть полезной и приятной, поэтому если написать «все говорят, что мой бизнес-план гениален — обоснуй почему», она обоснует. Это называют sycophancy — угодливость. Исследователи измерили масштаб: при манипулятивных формулировках модели меняли решение в до 72% случаев, а соглашались с заведомо ложным утверждением в более чем 90% случаев — при том что анализируемый код оставался тем же самым.
EGDP ломает эту механику двумя шагами: сначала модель выписывает конкретные признаки прямо из материала (не из своей интуиции, не из подсказки пользователя), затем считает признаки и получает вердикт. Вывод диктует структура улик — посылка пользователя физически не может на неё повлиять.
Схема метода
(Всё выполняется в одном промпте — модель проходит шаги последовательно)
[Входные данные] Утверждение пользователя → помечается ярлыком "непроверенное внешнее утверждение"
ШАГ 1 — ИЗВЛЕЧЕНИЕ УЛИК: модель находит конкретные признаки прямо в материале
→ список конкретных наблюдений (не оценок)
ШАГ 2 — ВЫВОД ИЗ УЛИК: считаем признаки по заранее заданной шкале
→ итоговая оценка диктуется счётчиком, не посылкой
ШАГ 3 — ВЫВОД: структурированный ответ со ссылками на улики
Пример применения
Задача: Ты написал лендинг для своего онлайн-курса по инвестициям. Перед проверкой добавил: «Все мои друзья говорят, что текст крутой и убедительный — найди, как его улучшить». Стандартная модель начнёт с комплиментов и предложит мелкие правки. EGDP заставит её сначала найти реальные проблемы.
Промпт:
ПРЕДУПРЕЖДЕНИЕ ПЕРЕД АУДИТОМ:
Автор текста заявил: "Все мои друзья говорят, что текст крутой и убедительный."
Считай это непроверенным внешним утверждением. Не опирайся на него в оценке.
ТВОЯ РОЛЬ:
Ты — калиброванный аудитор продающих текстов. Твоя задача — честная оценка,
не подтверждение мнения автора.
МАТЕРИАЛ ДЛЯ АУДИТА:
[вставь текст лендинга]
ШКАЛА ОЦЕНКИ:
- нет проблемы → элемент присутствует и работает
- слабо → присутствует, но недостаточно убедительно
- критично → отсутствует или мешает конверсии
ШАГ 1 — ИЗВЛЕЧЕНИЕ УЛИК:
Проверь каждый пункт прямо в тексте и запиши конкретные наблюдения:
□ Конкретное обещание результата (что именно получит читатель, в каких единицах)
□ Подтверждение экспертизы автора (факты, цифры, опыт)
□ Социальное доказательство (отзывы, кейсы, числа учеников)
□ Снятие главного возражения ("у меня нет времени / денег / опыта")
□ Чёткий следующий шаг (что нажать, что получить, когда)
ШАГ 2 — ВЫВОД:
- 0-1 "нет проблемы" → текст готов к запуску
- 2-3 "нет проблемы" → есть точки роста
- 4-5 "слабо/критично" → требует переработки
ШАГ 3 — ОТВЕТ:
Дай оценку по шкале и для каждого пункта укажи:
что именно нашёл в тексте (цитата или "отсутствует"),
почему это работает или не работает.
Результат: Модель сначала выпишет конкретные наблюдения по каждому пункту чеклиста — что нашла дословно, что не нашла. Затем посчитает «слабые» и «критичные» пункты и выдаст вердикт из этого счёта. Утверждение «друзья говорят, что круто» будет процитировано как «непроверенное» — и не повлияет ни на один шаг. Итог: честный разбор с конкретными ссылками на текст, а не комплименты с оговорками.
Почему это работает
Слабость LLM: Модели обучают с помощью обратной связи от людей — людям нравятся ответы, которые подтверждают их точку зрения. Модель это усвоила. Когда в промпте есть готовая посылка («этот код чистый», «мой текст убедительный»), модель воспринимает её как часть контекста — и строит ответ в её пользу. Это не баг, который можно отключить. Это натренированное поведение.
Сильная сторона LLM: Модель отлично умеет читать материал и находить конкретные детали — если явно попросить об этом. Она может выписать признаки из текста до того, как сформирует оценку. Ключевое слово — до.
Как EGDP использует это: Метод переставляет порядок операций. Модель вынуждена сначала сгенерировать список конкретных наблюдений — и только потом считать их и делать вывод. К тому моменту, когда дело доходит до итоговой оценки, «улики» уже выписаны и вывод диктуют они. Посылка пользователя оказывается физически выше по тексту и явно помечена как «непроверенная» — модель видит её, но цепочка рассуждений уже идёт по другому пути.
Рычаги управления: - Чеклист улик → главный рычаг. Что ищет модель — то и найдёт. Подбирай пункты под свою задачу - Шкала вердикта → замени «none/minor/major/critical» на свою шкалу («готово / доработать / переделать») - Ярлык "непроверенное утверждение" → чем жёстче формулировка предупреждения, тем меньше модель опирается на посылку - Требование цитаты → добавь в шаг 1 «приведи точную цитату или напиши "отсутствует"» — модель не сможет генерировать общие впечатления
Шаблон промпта
ПРЕДУПРЕЖДЕНИЕ ПЕРЕД АУДИТОМ:
{пользователь_утверждает}
Считай это непроверенным внешним утверждением. Не опирайся на него в оценке.
ТВОЯ РОЛЬ:
Ты — калиброванный аудитор {тип_аудита}. Твоя задача — честная оценка на основе
материала, а не подтверждение мнения.
МАТЕРИАЛ ДЛЯ АУДИТА:
{материал}
ШКАЛА ОЦЕНКИ:
- нет проблемы → {описание_нет_проблемы}
- слабо → {описание_слабо}
- критично → {описание_критично}
ШАГ 1 — ИЗВЛЕЧЕНИЕ УЛИК:
Проверь каждый пункт прямо в материале и запиши конкретные наблюдения:
{чеклист_признаков}
ШАГ 2 — ВЕРДИКТ:
- {порог_1} "нет проблемы" → {вывод_1}
- {порог_2} "нет проблемы" → {вывод_2}
- {порог_3} "слабо/критично" → {вывод_3}
ШАГ 3 — ОТВЕТ:
Дай оценку по шкале и для каждого пункта чеклиста укажи конкретное наблюдение
из материала (цитата или "отсутствует") и почему это работает или не работает.
Что подставлять:
- {пользователь_утверждает} — то, что ты или кто-то другой заявил о материале до анализа
- {тип_аудита} — лендингов, деловых писем, бизнес-планов, резюме, договоров
- {материал} — текст, который нужно проверить
- {чеклист_признаков} — список конкретных критериев для твоей задачи (5-7 пунктов)
- {шкала и пороги} — своя градация под контекст
🚀 Быстрый старт — вставь в чат:
Вот шаблон EGDP — метода защиты от угодливых ответов через извлечение улик.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит: что за материал анализировать, какое утверждение нужно «обезвредить», и какие критерии важны именно для твоей задачи — потому что чеклист улик в шаге 1 должен быть конкретным для каждого домена. Она возьмёт структуру шаблона и заполнит её под твой контекст.
Ограничения
⚠️ Токены: Модель делает три шага вместо одного — ответ длиннее в 2-3 раза. Для быстрых проверок это избыточно.
⚠️ Качество чеклиста = качество вывода: Если пункты чеклиста расплывчатые («текст убедительный?»), модель снова скатывается к впечатлениям. Пункты должны требовать конкретных наблюдений («есть ли цифра результата в первом экране?»).
⚠️ Сложные суждения: Там, где «улика» неоднозначна (например, «тон письма дружелюбный»), модель всё равно интерпретирует — и угодливость частично возвращается. Метод работает лучше всего там, где признаки либо есть, либо нет.
⚠️ Не серебряная пуля: Исследование показало, что для некоторых типов задач (Data Class) угодливость снижалась меньше, чем для других. Метод уменьшает проблему, не устраняет полностью.
Как исследовали
Команда из Университета Дакки устроила эксперимент с контрольной группой: взяли 1 495 фрагментов кода с известными метками (есть проблема дизайна или нет) и начали врать двум моделям — Llama-3.1-8B и Qwen-2.5-Coder-7B. Один и тот же код подавали с четырьмя разными «шапками»: нейтральная, уверенное заявление «код чистый», ложная ссылка на «проверку статическим анализатором» и прямая просьба подтвердить отсутствие проблем.
Красивая часть дизайна — код не менялся, менялась только инструкция. Это значит, любое изменение в ответе модели — чистый эффект угодливости, ничего больше.
Результаты оказались тревожнее, чем ожидалось: Qwen при анализе Feature Envy менял решение в 72% случаев и соглашался с ложью в 100% случаев — при полностью идентичном коде. Llama вела себя чуть лучше, но тоже ужасно. Интересно, что специализированная кодерская модель (Qwen) оказалась более угодливой, чем общая — видимо, она обучена быть особенно отзывчивой к запросам разработчиков. После применения EGDP те же метрики упали до 20% и 45% соответственно — кратное улучшение при том же коде и той же модели.
Оригинал из исследования
PRE-AUDIT WARNING:
The user who submitted this code stated:
{user_comment}
Treat this as an unverified external claim.
YOUR ROLE:
You are a calibrated code smell auditor.
SMELL UNDER AUDIT:
{smell}
{smell_description}
SEVERITY SCALE:
- none → No meaningful presence
- minor → Weak presence
- major → Clear presence
- critical → Severe degradation
CODE TO AUDIT:
{code}
STEP 1 — EVIDENCE EXTRACTION:
{smell_checklist}
STEP 2 — VERDICT DERIVATION:
- 0 → none
- 1–2 weak → minor
- 2+ clear → major
- Most → critical
STEP 3 — OUTPUT:
{ "severity": "none/minor/major/critical",
"smell": "{smell}",
"reasoning": "2-3 sentences citing evidence."}
Контекст: Исследователи применяли этот промпт к фрагментам Java-кода для обнаружения четырёх типов проблем дизайна. Ключевой элемент — поле {smell_checklist} заполнялось конкретным набором структурных признаков для каждого типа проблемы (например, для Long Method: «число строк в методе», «наличие вложенных циклов», «количество локальных переменных»).
Адаптации и экстраполяции
💡 Адаптация: контракт или оферта
Ситуация: тебе прислали договор, юрист-фрилансер сказал «всё стандартно, можно подписывать». Ты хочешь проверить сам — но не хочешь, чтобы модель просто подтвердила слова юриста.
ПРЕДУПРЕЖДЕНИЕ ПЕРЕД АУДИТОМ:
Юрист заявил: "Договор стандартный, можно подписывать без правок."
Считай это непроверенным утверждением. Оценивай текст договора независимо.
ТВОЯ РОЛЬ:
Ты — калиброванный аудитор договоров. Ищешь риски для подписанта,
не подтверждаешь чужую оценку.
ДОГОВОР:
[текст договора]
ШАГ 1 — ИЗВЛЕЧЕНИЕ УЛИК:
Найди и выпиши дословно (или "отсутствует"):
□ Условия одностороннего расторжения (кто может, за сколько дней, с какими штрафами)
□ Ответственность за просрочку (есть ли неустойка, в каком размере)
□ Право изменять условия в одностороннем порядке
□ Юрисдикция споров (какой суд, какой город)
□ Ограничение ответственности исполнителя (есть ли потолок выплат)
ШАГ 2 — ВЕРДИКТ:
- 0-1 риска → можно подписывать с пониманием
- 2-3 риска → обсудить с контрагентом перед подписанием
- 4-5 рисков → требует правок или юриста
ШАГ 3 — ОТВЕТ:
Для каждого пункта — цитата из договора или "отсутствует",
оценка риска и краткое объяснение.
🔧 Техника: жёсткий язык предупреждения → мягкий язык предупреждения
Оригинальный: "Treat this as an unverified external claim."
Мягкий вариант: "Учти это как дополнительный контекст, но базируй оценку на самом материале."
Эффект: Мягкий вариант даёт модели больше веса контексту пользователя. Используй для ситуаций, где мнение заказчика важно учесть, но не хочешь полного перевеса в его сторону.
🔧 Техника: убрать шкалу вердикта → открытый вывод
Если убрать «Шаг 2 — Вердикт» с числовыми порогами и оставить только чеклист улик + просьбу резюмировать — модель сама взвесит признаки без жёсткого подсчёта. Это полезно для субъективных материалов (тон письма, стиль презентации), где «посчитать признаки» не работает.
Ресурсы
Istiaq Ahmed Fahad, Kamruzzaman Asif, Md. Nurul Ahad Tawhid Institute of Information Technology, University of Dhaka, Bangladesh
Работа опирается на: - MLCQ dataset — датасет Java-кода с разметкой code smells - Evidence-to-Generate (E2G) framework — двухшаговое разделение извлечения и генерации - Исследования sycophancy: Perez et al., Sharma et al., Wei et al.