Reflection Pattern (Рефлексия)

1. Обзор концепции и системная проблема

Авторегрессионные языковые модели имеют фундаментальную архитектурную особенность: они генерируют токены последовательно и не имеют механизма аппаратного «отката» (Backtracking). Если в начале функции модель выбрала неоптимальный подход, механизм Self-Attention заставляет ее продолжать писать код в рамках этой ошибочной траектории:

1. Иллюзия уверенности: Модель генерирует код с галлюцинациями или пропущенными проверками на null/undefined с одинаково высокой уверенностью.
2. Пропуск крайних случаев (Edge Cases): При однопроходной генерации (Zero-Shot) внимание модели сфокусировано на базовом сценарии (Happy Path), в то время как обработка ошибок, race conditions и лимиты памяти игнорируются.
3. Низкое качество первого драфта: Как и инженер-человек, искусственный интеллект редко пишет безупречный архитектурный код с первой попытки без тщательного перечитывания.

Reflection Pattern вводит метакогнитивный цикл: модель превращается в собственного код-ревьюера, оценивая результат против четких инженерных критериев перед возвратом финального ответа.

2. Архитектурная таксономия и ментальная модель

Классическая реализация паттерна рефлексии состоит из трех специализированных компонентов:

• 1. Генератор (Producer / Generator): Принимает входные требования пользователя и генерирует первичное решение $S_0$. Фокусируется на решении функциональной задачи.
• 2. Критик (Auditor / Critic): Получает сгенерированный артефакт $S_0$ и оценивает его с позиции придирчивого архитектора или аудитора безопасности против структурированного чек-листа (сложность $O(N)$, утечки памяти, уязвимости OWASP, безопасность типов). Формирует детализированный список замечаний $C_0$.
• 3. Доработчик (Refiner): Получает исходный код $S_0$ вместе с критикой $C_0$ и генерирует обновленную версию $S_1$, в которой устранены все указанные недостатки.
• 4. Типы рефлексии:
  • Внутренняя (Internal Self-Reflection): критика осуществляется исключительно силами самой LLM с помощью специального промпта.
  • Привязанная к окружению (Grounded / External Reflection): критика основывается на объективных фактах — вывод компилятора, ошибки линтера или падения юнит-тестов.

3. Технический пайплайн и внутренняя механика

Жизненный цикл рефлексивного процесса:

1. Initial Drafting (Формирование первичного решения): Генератор создает кандидатное решение задачи.
2. Adversarial Critique (Аудит критика): Вызывается промпт критика с явной просьбой быть максимально строгим: «Проанализируй приведенный код. Найди как минимум 3 потенциальные точки падения, утечки памяти или крайние случаи, которые приведут к ошибке в продакшене».
3. Stopping Invariant Evaluation (Проверка критерия остановки): Оценивается результат критики: если критических замечаний нет или достигнут лимит раундов (iterations >= 2), система возвращает текущее решение.
4. Targeted Revision (Целевое доработка): Генератор получает системное сообщение: «Вот начальный код и замечания аудитора. Перепиши функцию, исправив каждое замечание без потери работоспособности».

4. Практические инженерные сценарии в продакшене

01. Аудит безопасности кода и смарт-контрактов

Генератор пишет функцию перевода средств в смарт-контракте Solidity. Критик анализирует код и указывает: «Строка 14 уязвима к атаке повторного входа (Reentrancy), поскольку изменение баланса происходит после вызова внешнего контракта». Рефайнер добавляет модификатор nonReentrant и переставляет обновление состояния перед отправкой средств (Checks-Effects-Interactions pattern).

02. Оптимизация производительности SQL и ORM запросов

Критик просматривает код, сгенерированный для чтения связанных сущностей, и предупреждает о проблеме $N+1$ запросов: «Использован цикл для обращения к связанным профилям; замените это на единый JOIN или eager loading через include».

03. Синтез надежных регулярных выражений

Составление регулярного выражения для валидации сложных email-адресов или телефонных номеров. На фазе рефлексии критик тестирует сгенерированный regex на 10 нестандартных крайних строках (ReDoS-атаки, пустые строки, спецсимволы) и указывает на случаи пробития фильтра.

5. Подводные камни, типовые ошибки и безопасность

• Сикофантия критика (Sycophancy): Если промпт критика сформулирован слишком мягко, модель склонна хвалить собственное решение («Код выглядит прекрасно!»), делая рефлексию фиктивной. Всегда диктуйте роль бескомпромиссного аудитора безопасности.
• Галлюцинованная критика (Over-Critique): Критик может выдумать проблему там, где ее нет, заставляя генератор усложнять простой и рабочий код лишними обертками. Привязывайте критику к реальным тестам и компилятору.
• Нескончаемое колебание (Oscillation): На первом шаге критик просит добавить проверку, на втором — убрать ее как избыточную. Обязательно фиксируйте максимальное количество шагов цикла.