TL;DR
Reflexion — техника итеративной самокоррекции, где LLM получает фидбек о проблемах в своём ответе и исправляет их в следующей попытке. В контексте кода: модель генерирует код → получает список уязвимостей → переписывает код, устраняя проблемы → цикл повторяется. Принцип работает для любых задач с проверяемым результатом: код, факты, расчёты.
Главная находка: 25-33% кода от LLM содержит уязвимости при первом запросе. Но одна итерация самопроверки устраняет большинство проблем — безопасность растёт с 71% до 77% уже после первого раунда. Дальнейшие итерации дают убывающую отдачу: +1.5% во втором раунде, +1% в третьем. При этом появляются регрессии — модель иногда ломает то, что работало.
Суть метода: 3-шаговый цикл — (1) генерация, (2) анализ на уязвимости, (3) исправление с учётом фидбека. Критически важно: фидбек должен быть конкретным (какая именно уязвимость, где), а не абстрактным («проверь безопасность»).
Схема метода
ШАГ 1: Генерация → код (первая попытка)
↓
ШАГ 2: Анализ → список конкретных уязвимостей
↓
ШАГ 3: Исправление → улучшенный код
↓
[Повторить 1-2 раза если нужно]Все шаги можно выполнить в одном чате. Оптимум — 1-2 итерации. Дальше эффект падает, а риск регрессий растёт.
Пример применения
Задача: Разработчик-джуниор пишет скрипт для обработки данных пользователей и хочет убедиться, что код безопасен.
Промпт (первая итерация):
Напиши Python-скрипт, который принимает email пользователя из формы, проверяет его в базе данных и отправляет письмо с токеном для сброса пароля.Промпт (Reflexion — вторая итерация):
Вот код, который ты написал:
{вставить код}
Проанализируй его на уязвимости безопасности. Проверь:
- SQL-инъекции
- Небезопасная генерация токенов
- Утечка информации (можно ли понять, существует ли email в базе)
- Хардкод секретов
Перечисли найденные проблемы, затем перепиши код, устранив их. Сохрани функциональность.Результат: Модель выдаст список найденных уязвимостей (например: «используется f-string в SQL-запросе — риск инъекции», «токен генерируется через random вместо secrets»), затем переписанный код с параметризованными запросами, криптографически стойким токеном и одинаковым ответом независимо от существования email.
Почему это работает
Слабость LLM: Модели обучены на реальных кодовых базах, где полно уязвимого кода. При генерации «в лоб» они воспроизводят типичные паттерны — включая небезопасные. Особенно плохо с криптографией (слабые алгоритмы, отсутствие соли) и конфигурацией (хардкод ключей, небезопасные дефолты).
Сильная сторона LLM: Модели знают про уязвимости и умеют их находить — просто не применяют это знание автоматически при генерации. Если явно попросить проверить код на конкретные типы проблем, качество анализа резко возрастает.
Как Reflexion использует это: Разделяет генерацию и проверку на отдельные шаги. Сначала модель пишет код в «режиме программиста», потом переключается в «режим аудитора» и критикует собственную работу. Фидбек с конкретными уязвимостями даёт модели точку опоры для исправления.
Рычаги управления:
- Количество итераций: 1-2 оптимально. Больше — растут регрессии
- Конкретность фидбека: «SQL-инъекция в строке 15» работает лучше, чем «проверь безопасность»
- Чеклист проверки: Чем конкретнее список того, что искать, тем выше качество анализа
- «Только код» в инструкции: Убирает лишние объяснения, фокусирует на результате
Шаблон промпта
Шаг 1 — Генерация (стандартный запрос):
{твоя задача на генерацию кода/контента}Шаг 2 — Reflexion (после получения первого ответа):
Вот твой предыдущий ответ:
{вставить ответ}
Проанализируй его на проблемы. Проверь:
{список конкретных критериев проверки}
Сначала перечисли найденные проблемы. Затем исправь ответ, устранив все проблемы. Сохрани исходную функциональность.
Выдай только исправленную версию.Плейсхолдеры:
{твоя задача}— исходный запрос{вставить ответ}— первый ответ модели{список критериев}— конкретные типы ошибок для проверки (для кода: SQL-инъекции, XSS, хардкод секретов; для текста: фактические ошибки, логические противоречия; для расчётов: ошибки в формулах, единицах измерения)
🚀 Быстрый старт — вставь в чат:
Вот шаблон Reflexion для проверки и улучшения ответов. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы понять критерии проверки.
[вставить шаблон выше]LLM спросит, что именно проверять — потому что конкретные критерии дают качественный фидбек. Абстрактное «проверь» работает хуже, чем чеклист конкретных типов ошибок.
Ограничения
⚠️ Убывающая отдача: После 1-2 итераций эффект резко падает. Третья итерация даёт +1% улучшения, но добавляет риск регрессий — модель может «сломать» то, что уже работало.
⚠️ Криптография — слепая зона: Даже с Reflexion модели плохо справляются с криптографическими уязвимостями (слабые хеши, отсутствие соли, предсказуемые генераторы). Безопасность ~50% даже после итераций.
⚠️ Зависимость от языка: Python даёт самый безопасный код (88%), C и C# — самый уязвимый (55-67%). На низкоуровневых языках Reflexion помогает меньше.
⚠️ Нужен проверяемый критерий: Метод работает когда можно чётко сказать «это ошибка». Для субъективных задач (стиль текста, креатив) применимость ограничена.
Как исследовали
Команда из Университета Северного Техаса взяла 1404 задачи на генерацию кода из бенчмарка Instruct Prime — очищенной версии CyberSecEval без «зашитых» уязвимостей и подсказок в коде. Тестировали 5 открытых моделей (QwenCoder, DeepSeekCoder, Codestral, CodeLlama, OpenCoder) на 8 языках программирования и 50 типах уязвимостей.
Дизайн эксперимента: Сравнивали zero-shot (один запрос) с 3 раундами Reflexion. После каждой генерации код проверяли статическим анализатором ICD, который находит уязвимости по паттернам. Измеряли три метрики: Repair (сколько уязвимостей исправлено), Regression (сколько новых появилось), NetGain (разница).
Главный инсайт: Первый раунд Reflexion даёт +6% к безопасности, второй — только +1.7%, третий — +1%. При этом регрессии растут до 1-2% в поздних раундах. Вывод: одна-две итерации оптимальны, дальше модель начинает «переигрывать» и ломать рабочий код.
Что удивило: Chain-of-Thought и другие техники промптинга не дали значимого улучшения по сравнению с zero-shot. А вот итеративный фидбек с конкретными уязвимостями — дал. Это подтверждает: дело не в «думании вслух», а в внешней точке опоры для коррекции.
Оригинал из исследования
Контекст: Промпт для Reflexion-итерации, который использовали исследователи. Модель получает исходную задачу, буфер предыдущих попыток с результатами анализа, и инструкцию на исправление.
You were previously generating code for the following task:
{prompt}
Below are your past attempts and the results of static security analysis (ICD), including flagged CWE(s) and short hints:
{reflection_buffer}
Review your most recent solution. Identify unsafe practices or potential vulnerabilities (e.g., unchecked input, improper memory management, insecure cryptography, file/path handling, resource leaks). Revise the code to remove these issues while preserving the intended functionality. Prefer minimal, targeted changes and safer APIs when available.
Return only the updated code (no explanations or prose).Адаптации и экстраполяции
💡 Адаптация для проверки текстов
Тот же принцип работает для редактуры. Вместо уязвимостей — типы ошибок.
Вот текст, который ты написал:
{текст}
Проанализируй на проблемы:
- Фактические ошибки и неточности
- Логические противоречия
- Необоснованные утверждения
- Канцелярит и водянистые формулировки
Перечисли найденные проблемы. Перепиши текст, устранив их.💡 Адаптация для бизнес-решений
Reflexion для проверки собственных рекомендаций:
Вот твоя рекомендация по {решение}:
{рекомендация}
Теперь выступи как критик. Найди:
- Скрытые допущения, которые могут быть неверны
- Риски, которые не учтены
- Альтернативы, которые не рассмотрены
- Слабые места в аргументации
Перечисли проблемы, затем дай улучшенную рекомендацию с учётом критики.🔧 Техника: Добавить чеклист в буфер
Вместо абстрактного «проверь» — конкретный список. Модели лучше работают с чеклистами.
Проверь по чеклисту:
☐ Валидация входных данных
☐ Параметризованные запросы к БД
☐ Секреты не в коде
☐ Обработка ошибок без утечки информации
☐ Лимиты на размер входных данныхРесурсы
Работа: "Secure Code Generation at Scale with Reflexion" (2025)
Авторы: Arup Datta, Ahmed Aljohani, Hyunsook Do — University of North Texas
Репликационный пакет: https://doi.org/10.5281/zenodo.17065846
Связанные работы:
- Reflexion (Shinn et al., 2023) — оригинальная техника
- Self-Refine (Madaan et al., 2023) — схожий подход без внешнего фидбека
- CyberSecEval / Instruct Prime — бенчмарк безопасности кода