Explainable AI

Explainable AI объединяет методы, которые помогают исследовать вклад признаков, сравнивать возможные решения и объяснять работу системы разным людям. Одно объяснение не доказывает справедливость или правильность модели: его сверяют с данными, процессом и реальными результатами.

Коротко

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

Зачем нужны объяснения

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

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

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

Интерпретируемость и объяснимость

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

Объяснимость шире. Сложную модель можно исследовать внешними методами и строить приближённое описание её поведения. Такое описание полезно, но не тождественно самой модели.

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

Локальные и глобальные объяснения

Локальное объяснение относится к одному примеру. Оно отвечает: почему эта заявка получила такой балл или какие области этого изображения сильнее повлияли на вывод.

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

Локальный результат нельзя автоматически переносить на весь датасет. И наоборот, средняя важность признака не объясняет каждый отдельный случай.

Основные методы

Вклад признаков

Методы семейства SHAP оценивают, насколько каждый признак сдвинул прогноз относительно выбранной базы. Результат зависит от фонового набора данных и допущений о зависимостях между признаками.

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

Контрфактуальные примеры

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

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

Карты важности для изображений

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

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

Примеры и ближайшие случаи

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

Документация системы

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

Наглядный пример

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

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

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

Для аудитора: версия модели, датасет проверки, частота ложных срабатываний по группам и правила ручного пересмотра.

Фраза «так решила нейросеть» не объясняет ничего. Но и один график SHAP не заменяет процедуру обжалования.

Как проверяют качество объяснения

У объяснения несколько независимых свойств:

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

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

Объяснение не равно доказательству

XAI не подтверждает автоматически, что модель:

• использует качественные данные;
• не дискриминирует;
• правильно оценивает причинность;
• защищена от сдвига распределения;
• соответствует требованиям закона;
• безопасна для выбранного сценария.

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

Правовой контекст

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

Ни GDPR, ни EU AI Act нельзя свести к универсальному правилу «любая нейросеть обязана объяснить каждый ответ». Для юридически значимого процесса требования проверяют по тексту нормы и у профильного специалиста, а техническое объяснение проектируют под эту обязанность.

Частые ошибки

• Принимать карту внимания за готовое объяснение. Связь внимания с причиной ответа нужно проверять отдельно.
• Показывать только один метод. Разные методы могут расходиться из-за разных допущений.
• Объяснять модель её же текстом. Свободный пересказ может звучать уверенно и не соответствовать вычислению.
• Игнорировать базовый уровень. Вклад признака зависит от того, с чем сравнивают прогноз.
• Забывать аудиторию. Инженерное объяснение и уведомление пользователю решают разные задачи.
• Скрывать неопределённость. Точная диаграмма не делает неточный прогноз надёжным.

Частые вопросы

Какая техника объяснимости лучше?

Та, которая отвечает на конкретный вопрос и проходит проверку верности. Для табличной модели это может быть вклад признаков и контрфактуал, для изображения — карта плюс тест с маскированием, для всего продукта — документация и анализ ошибок.

Можно ли объяснить языковую модель?

Можно исследовать чувствительность к контексту, анализировать источники, строить контрфактуальные запросы и проверять поведение тестами. Свободное «рассуждение» самой модели не считается точным отчётом о внутренних вычислениях.

Достаточно ли XAI для аудита?

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

Главное

Explainable AI — набор способов исследовать и сообщать, почему система ведёт себя определённым образом. Полезное объяснение соответствует аудитории, показывает ограничения и проверяется экспериментом. Оно помогает увидеть проблему, но не заменяет оценку качества, справедливости, безопасности и правовых обязанностей.

Требования к понятности, точности объяснений и границам знания рассматривает NIST. Правовой контекст для отдельных решений в ЕС описан, в частности, в статье 86 EU AI Act; её область применения ограничена условиями самой нормы.