Наукова робота на arXiv, опублікована у серпні 2026 року під ідентифікатором 2608.21345, ставить питання, яке практики агентних систем зазвичай вирішують інтуїтивно: скільки обчислювального бюджету в циклі self-refinement має піти на генерацію відповіді, а скільки — на її критику. Автори показують, що нерівномірний розподіл ресурсів між цими двома кроками напряму впливає на якість фінального результату, і пропонують оптимальні пропорції окремо для різних типів задач.
Для тих, хто будує reflect-and-refine цикли — коли модель спочатку генерує чернетку, потім критикує власний вивід, а тоді переписує його з урахуванням зауважень — це не абстрактна академічна деталь. Кожна ітерація такого циклу коштує токенів і часу, і питання «куди інвестувати ще один прохід: у нову генерацію чи в глибшу критику» постає буквально в кожному проєкті, де є бюджет на inference.
За даними arXiv, робота формалізує саме цей компроміс і пропонує підхід до підбору пропорцій замість підбору «на око», яким досі користується більшість команд.
Що саме дослідили автори?
Ядро роботи — аналіз self-refinement пайплайнів, у яких обчислення розподіляються між двома ролями: генератором, що видає чернетку відповіді, і критиком, що оцінює й дає зворотний зв'язок для наступної ітерації. Автори перевіряли, як зміна пропорції обчислень між цими кроками змінює якість підсумкового результату, і зафіксували, що асиметрія — коли одна роль отримує непропорційно більше ресурсів за рахунок іншої — систематично впливає на результат. Ключовий висновок: оптимальна пропорція не універсальна, вона залежить від типу задачі, тож автори пропонують окремі рекомендовані співвідношення для різних класів задач, а не одне «магічне число» на всі випадки.
Чому взагалі має значення, хто скільки «думає» — генератор чи критик?
Проблема, яку формалізує ця робота, добре знайома кожному, хто збирав agentic pipeline з циклом самоперевірки. Якщо весь бюджет піти на генератора, критик перетворюється на формальність — коротку перевірку, яка ловить хіба що явні помилки, і тоді додаткові ітерації генерації просто перемішують ту саму якість без реального покращення. Якщо ж навпаки перегодувати критика — довгі, деталізовані розбори, — а генератору лишити мінімум ресурсів на переписування, зворотний зв'язок виявляється точним, але модель фізично не встигає його якісно відпрацювати за один прохід.
На практиці це означає, що «просто додати ще одну ітерацію рефлексії» — не універсальний рецепт покращення якості. Ітерація, у якій критик отримує замало обчислень, щоб дати змістовний фідбек, або генератор — замало, щоб цей фідбек відпрацювати, витрачає бюджет, не рухаючи якість.
Що це змінює для дизайну агентних систем?
Практичний висновок для тих, хто налаштовує reflect-and-refine або generate-critique-revise цикли — почати ставитися до розподілу бюджету між генерацією і критикою як до окремого параметра дизайну, а не побічного ефекту довжини промптів. Це особливо стосується систем, де агенти вже розподіляють ролі й обчислення між собою — оптимальна пропорція генератор/критик, за логікою роботи, буде своя для коду, своя для довгих текстів, своя для математичних задач.
- Для задач з чіткими критеріями правильності (код, математика) критику варто давати відносно більше ресурсів — помилку легше знайти, ніж вигадати гарну відповідь з нуля.
- Для творчих і відкритих задач баланс, найімовірніше, зсувається у бік генератора — там менше формальних критеріїв, які критик міг би застосувати за короткий прохід.
- Фіксований поділ бюджету 50/50 між кроками, який часто ставлять за замовчуванням, за даними роботи, рідко буває оптимальним для конкретної задачі.
За нашою оцінкою, найпростіший спосіб застосувати цей висновок сьогодні — почати логувати, скільки токенів реально йде на генерацію проти критики у вже наявних self-refinement циклах, і поекспериментувати з явним зсувом пропорції для конкретного типу задач, замість того щоб множити кількість ітерацій без зміни балансу всередині кожної з них.
Висновок AiiN
Головна цінність цієї роботи — не в конкретних пропорціях, а в самій постановці питання: розподіл обчислень між генерацією і критикою — це такий самий параметр архітектури агентної системи, як кількість ітерацій чи вибір моделі, і його варто підбирати під задачу, а не копіювати з чужого пайплайну. Команди, що будують агентів з циклами самоперевірки, отримують привід перевірити типовий workflow «згенеруй → скритикуй → перепиши» на предмет того, чи не марнує він бюджет на непропорційно слабку критику або надто дороге переписування.
Що таке self-refinement пайплайн?
Self-refinement — це патерн, у якому модель послідовно покращує власний вивід: спочатку генерує чернетку, потім критикує її (сама або окремим викликом-критиком), а тоді переписує з урахуванням зауважень. Цикл може повторюватися кілька разів, поки якість не вийде на плато або не вичерпається бюджет ітерацій.
Чи означає це, що критику завжди варто давати більше ресурсів?
Ні — за даними роботи, оптимальна пропорція залежить від типу задачі, і однозначної відповіді «більше для критика завжди краще» дослідження не дає. Це радше аргумент на користь того, щоб підбирати баланс під конкретний клас задач, а не застосовувати одне фіксоване співвідношення до всього пайплайну.