Исследователи предложили пять проверок для объяснений поведения ИИ

Допустим, ваша команда нашла внутри языковой модели сигнал, который появляется перед опасным ответом. Возникает соблазн приглушить его и считать проблему закрытой. Но сначала придётся проверить, действительно ли этот сигнал управляет поведением и не получит ли модель тот же результат другим способом. Для разработчика это вполне знакомая история: убрать симптом проще, чем доказать, что исправлена причина.

Именно такой инженерный вопрос разбирает обзор Understanding AI from the Inside: The State of Mechanistic Interpretability for AI Safety. Авторы рассматривают методы изучения внутренних вычислений нейросетей и предлагают пять измерений для оценки объяснений. Вместе с обзором они заявляют набор учебных ноутбуков с воспроизводимыми примерами. Первоисточник.

Что значит заглянуть внутрь модели

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

Представим условного помощника службы поддержки. На обычных обращениях он работает нормально, а при появлении определённой фразы начинает выдавать запрещённые инструкции. Исследователь может искать различия во внутренних состояниях модели между этими двумя случаями. Затем — обучить небольшой классификатор, который замечает подозрительное состояние.

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

Для продуктовой команды здесь меняется формулировка задачи. Вместо расплывчатого «сделать модель объяснимой» появляется конкретный вопрос: поможет ли доступ к внутренним состояниям находить определённый класс сбоев лучше, чем проверка готовых ответов?

Красивое объяснение тоже нужно тестировать

Обзор отдельно рассматривает неполноту приближённых описаний модели, устойчивость найденных механизмов и ограничения вмешательств. Его практический смысл — напоминание, что обнаружение внутреннего признака и надёжное управление ответами требуют разных доказательств. Полный текст обзора.

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

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

Поэтому в отчёте об эксперименте полезнее видеть конкретные ошибки, условия проверки и стоимость обработки запроса. Одной эффектной визуализации внутренних связей для решения о запуске недостаточно. Особенно если команда собирается менять модель, язык запросов или пользовательский сценарий.

Что с этим делать разработчику и продакту

Если вы работаете с моделью только через API, сначала стоит выяснить, доступны ли вообще нужные внутренние состояния. Без такого доступа обсуждение вмешательств быстро упрётся в возможности поставщика. Для команды с доступом к вычислениям модели разумной отправной точкой будет небольшой эксперимент на одном известном типе отказов.

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

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