TL;DR
FDPR — метод доработки промпта по ошибкам, а не по ощущениям. Вы гоняете промпт на наборе примеров и вручную разбираете каждую ошибку: что выдала модель, почему это неверно, какой механизм рассуждения сломался и какая правка в промпте это предотвратит. Ошибки группируются в типы по причине (а не по внешнему виду). Затем за один круг чинится только самый важный тип, и прогон повторяется.
Главная находка: модель выдаёт много «находок», которые держатся на поверхностных признаках. Увидела слово password в названии переменной и объявила уязвимость. Придумала путь данных, которого в коде нет. Сравнение вариантов промпта по общей точности этого не показывает: цифра есть, а почему ошибается — непонятно. Поэтому чужие советы («примеры помогают», «роль помогает») дают противоречивые результаты. Всё зависит от модели и задачи.
Суть метода — цикл из пяти шагов: наблюдение и причина → таксономия и приоритет → правка одной категории → перепроверка → вывод принципов. В статье на задаче поиска уязвимостей в Java-коде число выдаваемых находок упало со 111 до 26. После ручной проверки ложных срабатываний не осталось ни у одной модели, при этом охват категорий уязвимостей сохранился.
Схема метода
ШАГ 1: Прогнать промпт на наборе примеров → записать каждую ошибку
(вывод модели + эталон + контекст)
ШАГ 2: Разобрать причину каждой ошибки → 4 вопроса:
что выдала? почему неверно? какой механизм рассуждения сломался?
какая правка промпта это предотвратит?
ШАГ 3: Сгруппировать по ПРИЧИНЕ (не по внешнему виду) → таксономия типов ошибок
Приоритет: частота, цена ошибки, цена проверки, повторяемость,
насколько ошибка лечится промптом
ШАГ 4: Починить ОДИН главный тип → одна правка промпта → новый прогон
(каждая правка привязана к типу ошибки)
ШАГ 5: Повторять, пока улучшений нет или остались ошибки, которые промптом
не лечатся → правки, которые стабильно работали, превратить в принципы
→ «заморозить» промпт и проверить на новых данных
Шаги 1–5 — отдельные запросы и ручная работа. Разбор причин можно отдать самой LLM, но решение «что считать ошибкой» остаётся за человеком.
Пример применения
Задача: Вы руководитель контент-отдела на маркетплейсе (Ozon, Wildberries). Нужен промпт, который помечает заказные отзывы. Первая версия помечает подозрительным всё, где много восклицательных знаков и слов «супер», «рекомендую всем». Живые довольные покупатели попадают под удар. Модерация тонет в ложных срабатываниях.
Промпт (шаг 2–3, разбор ошибок):
Ты помогаешь мне дорабатывать промпт для поиска заказных отзывов.
Ниже — 12 случаев, где промпт ошибся. Для каждого указано: текст отзыва,
что ответила модель, какой ответ верный (по решению модератора).
Для КАЖДОГО случая ответь на 4 вопроса:
1. Что выдала модель?
2. Почему это неверно?
3. Какой механизм рассуждения сломался (например: решила по
ключевому слову; придумала факт, которого нет в тексте; не учла
контекст категории товара)?
4. Какая правка в промпте это предотвратила бы?
Затем:
- Сгруппируй случаи в типы ошибок ПО ПРИЧИНЕ (механизму), а не по виду.
- Оцени каждый тип: как часто встречается, чем опасен (блокировка
честного покупателя дороже пропуска заказного), насколько легко
проверить вручную, лечится ли это правкой промпта.
- Назови ОДИН тип с наивысшим приоритетом и предложи ОДНУ правку промпта.
[текущий промпт]
[12 случаев]
Результат: Модель выдаст разбор по каждому случаю с четырьмя ответами. Затем покажет таксономию (например, «решение по стилю текста», «выдуманные признаки накрутки»). Потом даст таблицу приоритетов и одну предложенную правку. Эту правку вы вносите в промпт и прогоняете заново. Следующий круг — следующий тип ошибки.
Почему это работает
Слабость модели. Без явного требования доказательств модель идёт по самому простому признаку: слово, стиль, шаблон. Общий процент точности не говорит, какая именно привычка ломает ответ. Поэтому правки «наугад» то помогают, то вредят.
Сильная сторона. Модель хорошо исправляется, когда ей назвали конкретный механизм ошибки. Фраза «отметка без цитаты из текста недопустима» работает лучше, чем «будь внимательнее». Правку можно привязать к конкретному типу сбоя, а результат проверить на том же наборе.
Как метод это использует. Он заменяет угадывание диагностикой. Группировка по причине превращает россыпь разных ошибок в 3–4 повторяющиеся привычки. Правка одной категории за раз показывает, что именно помогло, и не создаёт новых ошибок.
Рычаги управления: - Размер набора разбора (12 случаев → 30) — больше случаев дают более надёжную таксономию, но разбор дольше. - Критерии приоритета — замените на свои: для юриста важнее цена пропуска, для маркетинга — цена ложной тревоги. - Условие остановки — «нет улучшения» или «остались ошибки, которые промптом не лечатся». Второе тоже результат: так вы находите, что нужен человек или другая модель. - Проверка на свежих данных — после доработки заморозьте промпт и прогоните на примерах, которые не видели при разработке.
Шаблон промпта
Шаблон 1. Разбор ошибок (шаги 1–3):
Ты — аналитик качества промптов. Твоя задача — найти повторяющиеся
причины ошибок, а не пересказать отдельные случаи.
{текущий_промпт}
{случай_1: вход | ответ модели | верный ответ | контекст}
{случай_2: ...}
...
Для каждого случая ответь:
1. Что выдала модель?
2. Почему это неверно?
3. Какой механизм рассуждения сломался?
4. Какая правка промпта это предотвратила бы?
Отдельно отметь случаи, где причина НЕ в промпте
(неоднозначные данные, ошибка в эталоне, ограничение модели).
Сгруппируй случаи по механизму ошибки. Дай каждому типу имя
и перечисли номера случаев.
Оцени каждый тип по критериям: {критерии_приоритета}.
Выбери ОДИН тип для следующей правки.
Шаблон 2. Какие правки использовали авторы (вид итогового промпта). Финальная версия в статье включала: роль аудитора; требование доказательного рассуждения (вход → путь → итог) до вывода; контрастные примеры «плохо / хорошо»; запрет на выводы без подтверждения; структурированный вывод с уверенностью и цепочкой доказательств. Для своей задачи их можно собрать так:
Ты — {роль}. Прежде чем сообщить о находке, покажи цепочку
доказательств: {шаг_1_откуда_данные} → {шаг_2_как_связано} → {шаг_3_вывод}.
Если цепочку по тексту собрать нельзя — находку не сообщай.
Примеры:
Неверно: {пример_ложной_находки} — потому что {механизм_ошибки}.
Верно: {пример_подтверждённой_находки}.
Формат ответа (JSON): {место, категория, уверенность, цепочка_доказательств}
Что подставлять: {критерии_приоритета} — что для вас дороже: частота, цена ошибки, цена проверки. {роль} и шаги цепочки — ваша задача. Примеры «неверно/верно» берите из реальных ошибок вашего промпта.
🚀 Быстрый старт — вставь в чат:
Вот шаблон FDPR для доработки промпта по разбору ошибок. Адаптируй под мою
задачу: [опиши задачу и что за промпт хочешь улучшить].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что считается ошибкой, какие критерии приоритета важны и какие у вас есть примеры сбоев. Это нужно, потому что метод работает на реальных ошибках вашего промпта. Она соберёт заготовку из шаблона и подстроит её под вашу задачу.
Ограничения
⚠️ Нужны реальные ошибки и эталон: метод не работает «в вакууме». Нужен набор примеров, где вы знаете верный ответ, и время на ручной разбор каждой ошибки.
⚠️ Нет сравнения с обычной доработкой: авторы не показали, что FDPR лучше, чем просто аккуратно править промпт. Показано, что последовательность правок снизила шум, но вклад самого метода отдельно не измерен.
⚠️ Падение «находок» ≠ рост качества: 111 → 26 — это число отчётов, проверенных вручную. Если делать то же на своей задаче, смотрите ещё и на пропущенные случаи. Иначе промпт станет слишком осторожным.
⚠️ Одна область и небольшая разработочная выборка: метод отлаживали на 13 учебных Java-программах и проверяли на уязвимостях. Перенос на другие задачи авторы называют лишь возможным, они его не проверяли.
⚠️ Локальные модели: тестировали открытые модели среднего размера при температуре 0, не топовые облачные. Привычки ошибок у ChatGPT, Claude и Gemini могут быть другими.
⚠️ Текст статьи неполон: во входных данных обрезан раздел результатов. Итоги внешней проверки на большом наборе (Juliet) в оценке не использованы.
Как исследовали
Идея простая: если промпты улучшают на глаз или по общему проценту, то ошибки теряются. Авторы взяли учебное приложение с уязвимостями (13 Java-программ, 10 категорий OWASP) и прогнали через четыре локальные модели: Qwen3-Coder-30B, Qwen3.5-35B, DeepSeek-Coder-6.7B и Llama-3.2-3B. Каждую найденную «уязвимость» проверили вручную: правда ли это, верна ли категория, есть ли доказательство в коде, не выдумана ли цепочка.
Ошибки группировали по механизму. Например, «нашла password в имени переменной» — это переобобщение по шаблону. «Придумала несуществующий путь данных» — выдуманное доказательство. Так получилось четыре версии промпта (v0 → v3). Находок стало: 111 → 49 → 37 → 26.
В базовой версии ни одна модель не покрыла все 10 категорий. Qwen3-Coder нашла 6 из 10, Qwen3.5 — 8, DeepSeek — 0, Llama — 1. После доработки у каждой модели ложных срабатываний не осталось, а вместе модели покрыли все 10 категорий.
Что удивило: последняя правка (v3) убрала искусственные ограничения на список категорий — и результат стал лучше. Жёсткие рамки в промпте тоже могут быть источником ошибок. Ещё часть «промахов» оказалась не ошибкой модели, а следствием смены классификации OWASP: эталон устарел. Вывод для практики: проверяйте не только промпт, но и сам эталон.
Для проверки на новых данных промпт заморозили и прогнали на наборе Juliet (около 40 тысяч программ, 112 типов слабостей) с вычищенными подсказками. Результаты этой части в доступном тексте обрезаны.
Адаптации и экстраполяции
🔧 Техника: добавить «правило цитаты» → меньше выдуманных находок
Из финального промпта статьи можно взять одно правило и вставить в любой промпт-проверяльщик (договоры, отзывы, резюме, тексты):
Каждое замечание сопровождай дословной цитатой из текста, на которую
оно опирается. Нет цитаты — замечания нет.
🔧 Техника: поручить разбор ошибок отдельному чату
Не смешивайте в одном чате «рабочий» промпт и «разбор его ошибок». Откройте новый чат, вставьте шаблон 1 и 10–15 случаев сбоя. Так модель не защищает собственный ответ.
Экстраполяция: FDPR для файла инструкций агента. Это идея по мотивам статьи, в ней она не проверялась. Если агент (например, Claude Code) стабильно ошибается — лишний рефакторинг, выдуманные функции, — соберите 10 таких случаев и прогоните через шаблон 1. Одну исправляющую правку внесите в CLAUDE.md и посмотрите, ушёл ли именно этот тип ошибки.
Ресурсы
- Работа: Learning from Failures: A Failure-Driven Prompt Refinement for LLM-Based Vulnerability Analysis
- Авторы: Mandana Ghadamian, David Mohaisen — University of Central Florida, Orlando, США
- Данные: Damn Vulnerable Java Application (DVJA), Juliet Test Suite v1.3 (Java)
- Модели: Qwen3-Coder-30B, Qwen3.5-35B, DeepSeek-Coder-6.7B, Llama-3.2-3B (через Ollama)