CRITIC: Чому самокорекція LLM потребує зворотного зв’язку від зовнішніх інструментів

Читаю CRITIC (Gou et al., ICLR 2024), розмірковуючи про те, що відбувається після того, як фінансовий агент припускається помилки. Reflexion підказав нам, що агенти можуть вчитися на невдачах протягом епізодів. CRITIC ставить більш гостре питання: чи може LLM виявити та виправити власні помилки за один прохід генерації — і якщо так, то що їй насправді для цього потрібно?

Стаття

CRITIC представляє фреймворк, у якому мовна модель генерує початковий результат, а потім ітерує через цикл «перевірка-корекція», використовуючи зовнішні інструменти — API пошуку для фактичних тверджень, інтерпретатор Python для коду та арифметики, та класифікатор токсичності для модерації вмісту. Цикл виконується протягом фіксованої кількості ітерацій (стаття повідомляє про ефективні результати приблизно після трьох корекцій), створюючи уточнений результат, який автори оцінюють за допомогою запитань і відповідей у вільній формі (TriviaQA, AmbigNQ, HotpotQA), математичного синтезу програм та зниження токсичності.

Центральне твердження полягає не в тому, що LLM можуть самокорегуватися власноруч. Швидше навпаки: цінність CRITIC полягає саме в заземленні критики у зовнішньому сигналі, який модель не може підробити. Без API пошуку покращення QA зводяться майже до нуля або стають від'ємними. Фреймворк працює, тому що інструмент повідомляє моделі те, чого вона справді не знала, а не тому, що модель стає надійним самоаудитором.

Ключові ідеї

• У застосуванні до ChatGPT, CRITIC забезпечує покращення F1-метрики в середньому на 7,7 у трьох завданнях QA з відкритим доменом та абсолютний приріст у 7,0 відсоткових пунктів у трьох тестах математичного мислення.
• Зниження токсичності є найбільш вражаючим поодиноким результатом: ймовірність токсичності в оцінюваному наборі даних зменшилася на 79,2%.
• Видалення API пошуку призводить до того, що продуктивність QA або виходить на плато, або деградує — внутрішня здатність моделі до самокритики майже марна для фактологічних завдань.
• Цикл швидко сходиться: три раунди корекції дають більшу частину приросту, а подальші ітерації мають спадну віддачу.
• Фреймворк є незалежним від моделі та не потребує донавчання; він працює з API «чорної скриньки», включаючи Text-Davinci-003 та ChatGPT.
• CRITIC перевершує self-consistency (голосування більшістю за кількома зразками) у більшості завдань, що є значущим, оскільки self-consistency не має витрат на використання інструментів на кожному кроці.

Що підтверджується — а що ні

Основний емпіричний результат є ґрунтовним: зворотний зв’язок від зовнішніх інструментів суттєво покращує результати, а абляційне дослідження з видаленням API пошуку є нищівним для прихильників наївної самокорекції. Стаття також чесно описує механізм — покращення відбуваються завдяки інструменту, а не завдяки якійсь емерджентній метакогнітивній здатності.

Недостатньо дослідженою, на мій погляд, залишається таксономія збоїв. Коли модель генерує невдалу критику, яка ще далі віддаляє її від правильної відповіді? Стаття повідомляє про середню продуктивність, але дисперсія за завданнями та типами питань мала б величезне значення для впровадження. У фінансовому контексті найгіршим результатом є не «відсутність покращення», а переконлива на вигляд корекція, яка вносить нову помилку.

Вибір обмежитися трьома ітераціями також представлений радше як практична зручність, аніж як принциповий критерій зупинки. Три раунди можуть працювати для TriviaQA, де є еталонна відповідь, до якої можна прагнути. У такій галузі, як звірка бухгалтерських книг, де «правильна» відповідь вимагає міркувань над кількома документами та знання предметної області, не є очевидним, що трьох викликів інструментів буде достатньо — або що пошуковий API загального призначення взагалі надасть правильний сигнал для верифікації.

Супутня стаття ICLR 2024 «Large Language Models Cannot Self-Correct Reasoning Yet» (Huang et al., arXiv:2310.01798) підтверджує власні висновки CRITIC з іншого боку: без зовнішнього зворотного зв’язку самокорекція надійно погіршує точність міркувань. Ці дві роботи разом формують цілісну картину: те, що люди називали «самокорекцією», здебільшого є уточненням на основі зовнішнього зворотного зв’язку, і ця різниця має значення.

Чому це важливо для фінансового ШІ

Цикл CRITIC природним чином накладається на проблему безпеки зворотного запису (write-back safety) в агентах Beancount. Наразі, коли LLM-агент пропонує запис у журналі — наприклад, категорію транзакції або розподіл витрат — не існує принципового способу перевірити власний результат перед збереженням на диск. Архітектура CRITIC пропонує конкретний паттерн: згенерувати кандидатний запис, потім запустити верифікацію за допомогою інструменту (функція перевірки балансу, механізм правил, детектор дублікатів) і використати результат інструменту для спонукання до перегляду перед фіксацією запису.

Результат щодо токсичності — це аналогія, яку я вважаю корисною: зниження порушень політики на 79,2% відбувається не завдяки тому, що модель засвоює правила, а завдяки класифікатору, який повідомляє моделі про порушення. Для книги Beancount еквівалентом був би засіб перевірки правил, який позначає транзакції з подвійним обліком або порушення категорій і передає цей сигнал у цикл перегляду агента. Агенту не потрібно самостійно знати, що правила порушені; йому потрібен сигнал інструменту.

Критичним обмеженням для фінансів є залежність від API пошуку. Фінансовим агентам потрібні специфічні для галузі інструменти верифікації: перевірка цілісності залишків на рахунках, валідатори плану рахунків, пошук податкових правил. Звичайний вебпошук навряд чи виявить неправильно класифіковані витрати. Створення правильного рівня інструментів для корекції в стилі CRITIC у бухгалтерському обліку — це те, де полягає справжня інженерна робота, а стаття взагалі не розглядає розробку інструментів для конкретних галузей.

Що почитати далі

• «Large Language Models Cannot Self-Correct Reasoning Yet» (Huang et al., 2023, arXiv:2310.01798) — прямий емпіричний аргумент того, що внутрішня самокорекція не працює; варто читати разом із CRITIC, оскільки вони досліджують той самий механізм з протилежних сторін.
• «Tree of Thoughts: Deliberate Problem Solving with Large Language Models» (Yao et al., NeurIPS 2023, arXiv:2305.10601) — розширює ідею однопрохідної критики та корекції до дерева пошуку по проміжних кроках; актуально для багатокрокової звірки, де агенту потрібно досліджувати варіанти та повертатися назад.
• «ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs» (Qin et al., 2023, arXiv:2307.16789) — досліджує, як агенти вчаться вибирати та поєднувати виклики інструментів, що є проблемою попереднього етапу, яку CRITIC сприймає як належне.