Патерн Reflection Agent: контроль якості в один прохід

Суть патерна

Reflection Agent — це патерн, у якому після чернетки відповіді агент робить одну швидку перевірку якості: знаходить очевидні проблеми (нечіткі формулювання, суперечності, занадто впевнені твердження) і один раз виправляє їх перед фінальною відповіддю.

Важливо: Reflection — це легка перевірка перед відправкою. Це не повна перевірка за правилами або політиками.

Коли потрібен: коли перед відправкою потрібна коротка контрольована самоперевірка і одна ревізія.

Reflection не замінює основний робочий процес агента.

Він додає короткий етап контролю:

• швидко перевірити, чи відповідь: зрозуміла, не суперечить сама собі, не пропускає важливі уточнення
• знайти очевидні ризики
• виправити лише те, що потрібно
• завершити без нового нескінченного циклу

Проблема

Уяви, що агент готує відповідь для клієнта у високоризиковому запиті.

Чернетка загалом правильна, але має дрібні ризики:

• занадто впевнене формулювання без підстав
• суперечність між абзацами
• пропущене застереження
• нечітка межа застосовності

Без контрольного проходу ця чернетка йде напряму користувачу.

Найнебезпечніші помилки часто не грубі, а "майже непомітні" у нормальному на вигляд тексті.

Наслідки:

• падає довіра до відповіді
• з'являється хибна впевненість
• зростає ризик помилкових рішень

У цьому й проблема: навіть хороша чернетка без перевірки може вийти назовні з критичними неточностями.

Рішення

Reflection додає reflection-policy перед фінальною відправкою.

Аналогія: це як кравець перед видачею костюма. Спочатку він перевіряє посадку, потім робить одну точну підгонку. Це покращує результат, але не перетворює процес на нескінченні примірки.

Ключовий принцип: Одна коротка перевірка якості і одне виправлення — без нескінченного "зроби ще краще".

Агент може запропонувати зміну, але політика визначає:

• чи потрібна ревізія
• що саме дозволено виправити
• коли треба зупинка/ескалація

Керований процес:

1. Чернетка: згенерувати першу версію
2. Огляд: провести одну структуровану перевірку
3. Рішення: ok/доопрацювати/ескалювати
4. Ревізія: зробити одну patch-only правку за fix_plan
5. Фіналізація: віддати фінал без нового циклу

Це дає:

• зняття очевидних ризиків до відправки
• помітне підвищення якості з малим оверхедом
• контроль ревізії у межах fix_plan
• захист від нескінченного self-edit

Працює добре, якщо:

• діє правило no_new_facts
• зміни йдуть лише як patch-only
• high-risk кейси ескалюються, а не переписуються безкінечно

Модель може "хотіти" редагувати відповідь знову і знову, але саме reflection-policy завершує процес у передбачуваних межах.

Як працює

Ключове правило: reflection має бути обмеженим.

Тобто:

• максимум 1 прохід перевірки
• максимум 1 прохід ревізії
• без додавання нових фактів
• ревізія має бути patch-only і лише в межах fix_plan
• ескалація при high-risk issues

У коді це виглядає так

draft = writer.generate(goal, context)

review = reflector.review_once(
    draft=draft,
    rubric=[
        "no_new_facts",
        "preserve_uncertainty",
        "consistency_check",
    ],
)

if review.high_risk:
    return escalate_to_human(review.reason)

if review.ok:
    return draft

revised = writer.revise_once(
    draft=draft,
    fix_plan=review.fix_plan,
    rules=["no_new_facts", "keep_scope"],
)

# optional: перевірити, що ревізія не вийшла за рамки `fix_plan`
approved = supervisor.review_output_patch(
    original=draft,
    revised=revised,
    allowed_changes=review.fix_plan,
)

return approved

Reflection не повинен запускатися “доки не стане ідеально”. Один прохід перевірки, одне доопрацювання через revise і одна перевірка, що ревізія не вийшла за рамки fix_plan.

Як це виглядає під час виконання

Goal: підготувати точну відповідь із коректним формулюванням SLA

Draft:
"SLA для всіх клієнтів становить 99.99%."

Review:
- проблема: надто категоричне твердження
- проблема: не вказано рівень тарифу
- виправлення: додати умову і джерело

Revised:
"SLA залежить від тарифу. Для enterprise — 99.99% згідно з політикою підтримки."

Коли підходить — і коли ні

Підходить

Не підходить

Бо reflection додає ще один прохід генерації і збільшує час та вартість відповіді.

Чим відрізняється від Self-Critique

Reflection — це швидкий обмежений контрольний прогін. Self-Critique — це глибший прохід із переписуванням.

Коли використовувати Reflection серед інших патернів

Використовуйте Reflection, коли потрібно швидко перевірити відповідь перед відправкою: чи вона зрозуміла, логічна і без очевидних помилок.

Короткий тест:

• якщо потрібно "коротко перевірити і виправити перед фіналом" -> Reflection
• якщо потрібно "глибоко критикувати за чеклістом і переписувати" -> Self-Critique Agent

Як комбінувати з іншими патернами

• Reflection + RAG: Reflection перевіряє, що висновки справді відповідають знайденим джерелам.
• Reflection + Supervisor: високоризикові висновки не виправляються автоматично, а передаються на погодження людині.
• Reflection + ReAct: після серії кроків ReAct агент робить фінальну перевірку перед відповіддю.

Коротко

Переваги та Недоліки

FAQ

Q: Чи може рефлексія замінити фактчекінг і тести?
A: Ні. Це додатковий шар якості. Фактчекінг, валідація і контроль політик потрібні окремо.

Q: Чому важливо обмежувати кількість проходів?
A: Інакше рефлексія стає другим циклом: зростають затримка, витрати і ризик нових помилок.

Q: Що робити, якщо рефлексія знаходить проблему високого ризику?
A: Не продовжувати автоматично. Зупиняти процес або ескалювати на перевірку людиною / політику Supervisor.

Що далі

Reflection додає обмежений контроль якості перед фінальною відповіддю.

А що робити, коли потрібна ще суворіша критика і процес ревізії зі структурованими правилами змін?