Патерн Self-Critique Agent: чернетка → критика → правка

Суть патерна

Self-Critique Agent — це патерн, у якому агент спочатку пише чернетку, потім за шаблоном фіксує ризики й обов’язкові правки, робить одну контрольовану правку і записує що саме змінилось у журналі змін.

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

На відміну від легкого reflection, self-critique зазвичай суворіший:

• критика має фіксований формат (наприклад, JSON)
• правки можна робити лише за правилами
• контроль приросту тексту
• система зберігає журнал змін (що було → що стало)

Проблема

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

Чернетка:

"Реліз затримано через збій у платіжному модулі."

Потім надходить запит:

"Зроби формулювання м'якшим."

Без self-critique рамки агент часто робить "красиве переписування", яке виходить за межі задачі:

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

"Покращити формулювання" не має перетворюватися на "змінити сенс".

У підсумку:

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

У цьому й проблема: під час "покращення" агент може змінити зміст, хоча мав змінити тільки форму.

Рішення

Self-Critique вводить правило: правити можна тільки те, що записано в "обов’язкових правках".

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

Ключовий принцип: Спочатку структурована критика, потім одна контрольована ревізія зі слідом аудиту.

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

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

1. Чернетка: згенерувати першу версію
2. Критика: сформувати артефакт (risks + required_changes)
3. Рішення: ok/доопрацювати/ескалювати
4. Ревізія: зробити одну обмежену ревізію
5. Аудит: записати diff + metadata

Це дає:

• покращення ясності без зміни фактів
• чітке розділення "що не так" і "що виправлено"
• відтворюваність правок
• контроль high-risk відповідей до публікації

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

• critique має фіксовану структуру (schema-driven)
• revision обмежена required_changes
• діє no_new_facts
• обов'язковий audit diff

Як працює

Щоб патерн був безпечним, потрібні чіткі межі:

• одна перевірка
• одна правка
• не додавати нових фактів
• правити тільки те, що в списку обов’язкових правок
• не роздувати текст (наприклад, +20% максимум)
• при високому ризику — стоп або перевірка людиною

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

draft = writer.generate(goal, context)

critique = critic.review_once(
    draft=draft,
    schema="risks_required_changes_v1",
)

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

if critique.ok:
    return draft

revised = writer.revise_once(
    draft=draft,
    required_changes=critique.required_changes,
    rules=[
        "no_new_facts",
        "max_length_increase_pct=20",
        "keep_scope",
    ],
)

approved = supervisor.review_output_patch(
    original=draft,
    revised=revised,
    allowed_changes=critique.required_changes,
)

audit.log_diff(
    before=draft,
    after=approved,
    risks=critique.risks,
)

return approved

Self-Critique не повинен запускатися "до ідеалу". Один critique + одне доопрацювання (revise), і перевірка, що revision не вийшов за межі required_changes.

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

Goal: запропонувати безпечний план дій під час мережевого інциденту

Draft:
"Проблема викликана мережею. Потрібно перезапустити весь кластер."

Critique:
- risk: твердження про причину без доказів
- risk: занадто широкий вплив дії
- required_change: додати перевірки перед restart

Revision:
"Ймовірна причина - мережевий збій.
Перед перезапуском кластера перевірити стан вузлів і затримку.
Якщо підтверджено частковий збій - перезапустити лише affected nodes."

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

Підходить

Не підходить

Бо self-critique додає другий крок генерації і підвищує вартість виконання.

Чим відрізняється від Reflection

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

Коли використовувати Self-Critique (vs інші патерни)

Використовуйте Self-Critique, коли потрібна глибока критика за явними критеріями і контрольоване переписування.

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

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

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

• Self-Critique + RAG: критика і правки дозволені лише в межах фактів із retrieval-контексту.
• Self-Critique + Supervisor: ризикові правки не застосовуються автоматично, а передаються на ручне погодження.
• Self-Critique + Reflection: Reflection робить швидкий pre-check, а Self-Critique вмикається для складних або спірних відповідей.

Коротко

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

FAQ

Q: Чи можна робити кілька критичних проходів?
A: Технічно можна, але це швидко перетворюється на дорогий цикл. Базовий безпечний стандарт: 1 + 1.

Q: Навіщо обов'язково логувати зміни?
A: Без diff складно зрозуміти, що саме змінило якість відповіді і де виникла помилка.

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

Що далі

Self-Critique покращує якість через кероване переписування.

Але що робити, якщо відповідь треба не просто переписати, а перевірити перед ризиковою дією за політиками?