CRITIC
CRITIC — это паттерн, в котором модель не пытается исправить себя "изнутри" на голом тексте, а использует инструменты для критики собственного ответа. Она может вызвать search, кодовый интерпретатор, калькулятор или другой внешний источник проверки, получить сигнал о проблеме и только потом переписать результат.
В 2026 это один из самых практичных verification-подходов, потому что он отражает реальную инженерную среду: сильные LLM-приложения почти никогда не живут в полной изоляции. Если ответ можно проверить через внешний инструмент, лучше сделать это, чем просить модель просто "подумать ещё раз".
Почему техника работает
У многих self-correction-подходов одна и та же слабость: модель критикует себя тем же интеллектом, который только что ошибся. Иногда это помогает, но часто нет. CRITIC усиливает критику за счёт внешнего сигнала.
Это меняет механику:
- модель не просто "размышляет ещё раз";
- она сталкивается с независимой проверкой;
- после этого revision становится более grounded.
Именно поэтому техника полезна не только для factual QA, но и для вычислений, code generation, policy checking и structured outputs.
Где CRITIC особенно полезен
Подход хорошо работает, когда есть доступный инструмент проверки:
- search для factual claims;
- calculator или Python для чисел;
- schema validator для JSON;
- SQL runner для запросов;
- unit tests для кода;
- policy engine для правил.
Это делает технику очень "продуктовой". Она легко ложится на современные agent runtimes и verification-pipelines.
Как выглядит хороший цикл
Где техника переоценена
CRITIC не значит "подключите любой tool и всё станет надёжным".
- Если tool слабый, noisy или сам ненадёжен, verification мало что даст.
- Если модель проверяет не тот claim, она может усиленно валидировать второстепенную деталь и пропустить главную ошибку.
- Если revision-подсказка слишком свободная, модель снова начнёт галлюцинировать поверх корректного tool output.
То есть сила CRITIC не просто в tool-use, а в узком и дисциплинированном контуре критики.
Когда CRITIC действительно даёт новый сигнал
Техника особенно сильна не там, где tool просто подтверждает очевидное, а там, где без внешней проверки модель склонна уверенно ошибаться:
- арифметика и unit conversion;
- claims о product features и policy rules;
- SQL, code и structured outputs, которые можно прогнать через validator;
- аналитические выводы, где можно проверить одну ключевую предпосылку.
Если tool-check ничего не меняет в решении или постоянно проверяет второстепенные детали, CRITIC становится декоративным слоем, а не реальной защитой от ошибок.
Как понимать технику в 2026
Сегодня CRITIC полезно видеть как bridge между prompting и agent engineering. Это уже не просто prompt trick, а архитектурный паттерн:
- answer generation;
- risk localization;
- external verification;
- controlled rewrite.
Во многих практических системах именно такой контур даёт наилучшее соотношение качества и стоимости. Он дешевле полного multi-agent review и надёжнее простой команды "перепроверь себя".
Когда её стоит добавлять
Техника особенно оправдана, если:
- у ответа высокая цена ошибки;
- проверка конкретного claim дешёвая;
- есть понятные tools;
- нужно сохранить original draft, но снизить hallucination rate.
Хорошие примеры: финансовые расчёты, product facts, pricing pages, ответы по policy, технические summary с обязательной атрибуцией.
Слабый сценарий для CRITIC: когда у задачи нет дешёвого и точного external oracle. В таком случае вы добавляете orchestration cost, но не получаете по-настоящему независимого verification signal.