Проверка с помощью самокритики

Самокритика использует LLM для оценки вывода LLM по набору критериев или политике. Она обнаруживает сложные сбои, которые невозможно выразить с помощью детерминированных валидаторов: фактические противоречия, проблемы с тоном, недостаточную полезность и незаметные нарушения политики.

Это дополнение на основе модели к валидаторам схем и правил.

Запускайте критику как отдельный вызов с собственной инструкцией, а не как заключительную инструкцию при генерации. Критик с изолированным контекстом, которого просят только оценивать, гораздо надёжнее, чем автор, которому предлагают оценить себя во время генерации: в последнем случае он склонен предвзято поддерживать собственный ответ.

Пусть критик формирует структурированные вердикты, чтобы конвейер мог действовать программно. Критика в свободной форме непригодна для машинной обработки.

Объединяйте критика с редактором. Критик находит проблемы, автор исправляет ответ с учётом критики, после чего цикл повторяется до получения положительного результата или исчерпания бюджета. Это аналог цикла исправления на основе модели.

Расплывчатая инструкция ('это хорошо?') приводит к нестабильным вердиктам. Конкретные критерии оценки с явными проверяемыми условиями дают согласованные результаты. Разбейте оценку на вопросы с ответами «да» или «нет», на которые критик отвечает по отдельности.

Для обнаружения галлюцинаций предоставьте критику контекст источника и попросите отметить любое утверждение, которое из него не следует. Так самокритика превращается в проверку логического следования и становится гораздо надёжнее, чем вопрос «это правда?» без доказательств.

Критик сам является LLM и может ошибаться:

• Поддакивание — бездумное одобрение ответа автора.
• Излишняя критика — пометка правильного вывода как ошибочного.
• Общие слепые зоны — одна и та же модель не замечает одни и те же ошибки.

Снижайте эти риски, используя для критики модель из другого семейства, строгую роль рецензента и откалиброванные пороги.

Критик не обязательно должен быть самой дорогой моделью. Часто меньшая модель с чёткими критериями оценки служит экономичным фильтром, а использование модели из другого семейства уменьшает общие слепые зоны. Самую сильную модель оставляйте для написания ответа.

Самокритика снижает количество ошибок, но не является доказательством. Для материалов с низкими рисками достаточно одного прохода критики. Для выводов с высокими рисками объединяйте самокритику с детерминированными валидаторами и проверкой человеком; никогда не позволяйте модели быть единственным арбитром в решениях, критичных для безопасности.

Самокритика примерно вдвое увеличивает число вызовов на запрос. Контролируйте это: запускайте критику только после детерминированных проверок, кэшируйте критику для одинаковых черновиков и ограничивайте число раундов исправления. По возможности выполняйте критику параллельно с неблокирующей работой.

Проверьте критика, прежде чем доверять ему. Создайте набор выводов, размеченных людьми, запустите критика и измерьте согласие — точность и полноту относительно человеческих вердиктов. Настраивайте критерии оценки и роль, пока суждения критика не начнут коррелировать с человеческими; повторяйте проверку после обновления модели.

Проверка с помощью самокритики:

• Отдельный критик с чистым контекстом оценивает вывод автора.
• Формируйте структурированные вердикты и запускайте цикл «критика — затем исправление».
• Конкретные критерии оценки и проверки логического следования с опорой на источники повышают надёжность.
• Остерегайтесь поддакивания и общих слепых зон; используйте другую модель в роли критика.
• Учитывайте стоимость, объединяйте проверку с детерминированными проверками и калибруйте её по оценкам людей.

Вы завершили изучение защитных механизмов. Следующий курс: атакующее тестирование и состязательная оценка.