Объяснимость требуется не каждой модели в одинаковом объеме. Для подсказки следующего товара и для решения, влияющего на кредит, найм или доступ к услуге, последствия ошибки различаются. Требования к объяснению определяются сценарием, данными, ролью человека и тем, кто будет использовать результат.
Три разных задачи под одним словом
Интерпретируемость описывает, насколько человек может понять устройство модели. Локальное объяснение показывает, какие признаки повлияли на конкретный прогноз. Объяснение решения включает более широкий контекст: какие данные использовали, какое правило применили после прогноза, кто утвердил действие и как его можно оспорить.
SHAP или список значимых признаков закрывает только часть задачи. Если модель формирует балл, а итоговый отказ возникает из последующего бизнес-правила, объяснять нужно всю цепочку.
Глобальное, локальное и контрфактическое объяснение
Глобальное объяснение описывает общую логику модели: какие группы признаков влияют на результат, где качество ниже и в каких данных модель обучалась. Локальное относится к одному прогнозу. Контрфактическое показывает, какое допустимое изменение входа могло бы привести к другому результату.
Эти формы отвечают разным пользователям. Команде управления риском нужна общая картина и ограничения. Оператору — причина конкретного сигнала. Человеку, которого затронуло решение, — понятное основание и доступный путь пересмотра. Один и тот же график вклада признаков редко подходит всем трем аудиториям.
Что уже регулируется в России
В России нет единого горизонтального закона об искусственном интеллекте, построенного по модели EU AI Act. Автоматизированные решения при этом попадают под действующие нормы.
Статья 16 закона № 152-ФЗ регулирует решения, основанные исключительно на автоматизированной обработке персональных данных, если они создают юридические последствия для человека или затрагивают его права и законные интересы. Для скоринга, найма и других чувствительных процессов нужно проверить состав данных, правовое основание, роль человека, способ уведомления и порядок оспаривания.
EU AI Act применяется по установленной сфере действия, а не по самому факту иностранного партнерства. Для конкретной системы проверяют, выводится ли она на рынок ЕС, используется ли в ЕС, кто выступает поставщиком и оператором и к какой категории риска относится сценарий. Правовой вывод требует анализа фактической схемы использования.
Что должен уметь бизнес-контур
Первый уровень — воспроизводимость. Для решения должны сохраняться версия модели, версия признаков, входные данные, правила после модели и время расчета. Без этого невозможно восстановить причину результата.
Второй уровень — понятное объяснение для роли. Дата-сайентисту нужны распределения и вклад признаков. Риск-менеджеру — связь с политикой и лимитами. Клиенту или сотруднику — ясное описание факторов и доступного порядка пересмотра без раскрытия коммерческой тайны сверх требуемого объема.
Третий уровень — проверка устойчивости. Команда смотрит, меняются ли объяснения после небольших изменений входа, не используются ли прокси чувствительных признаков и одинаково ли работает процедура для разных групп.
Как выбрать метод
Линейная модель или небольшое дерево могут быть достаточно прозрачными сами по себе. Для сложных ансамблей и нейросетей применяются локальные и глобальные методы объяснения. Они тоже имеют ограничения: объяснение может быть нестабильным, зависеть от фоновой выборки и создавать убедительную картинку без причинного смысла.
Выбор метода фиксируется в протоколе проверки. Там указывают пользователя объяснения, решение, допустимую задержку, ограничения метода и тесты стабильности. Для решений с существенными последствиями полезно сравнить сложную модель с более простой базовой и проверить, оправдывает ли прирост качества потерю прозрачности и рост стоимости контроля.
Где объяснение может ввести в заблуждение
Метод объяснения строит приближение к поведению модели. Он не доказывает причинность и не гарантирует, что признак допустимо использовать. Высокий вклад почтового индекса может отражать географию, доход или историческое смещение данных. Технический отчет должен отмечать такие прокси и показывать тесты по релевантным группам.
Стабильность тоже проверяется. Если небольшое изменение несущественного поля полностью меняет объяснение при близком прогнозе, использовать его для спорного решения опасно. Команда тестирует несколько методов и фиксирует версию библиотеки, фоновые данные и параметры.
Приемка системы у поставщика
В договор и программу испытаний стоит включить выгрузку входных данных и версии модели для конкретного решения, описание ограничений метода, время построения объяснения и формат журнала. Заказчик должен иметь возможность воспроизвести спорный случай в контролируемом контуре.
Отдельно проверяется роль человека. Кнопка «подтвердить» не превращает автоматизированное решение в содержательный ручной контроль, если сотрудник не видит оснований, не может изменить результат или отвечает за недостижимый срок обработки.
Эксплуатационный контроль
После запуска полезно отслеживать точность модели, долю решений на ручном пересмотре, причины отмены автоматического результата, стабильность объяснений и обращения пользователей. Эти данные показывают, где описание модели расходится с реальным процессом.
Минимальный пакет перед запуском
- карта данных и признаков;
- описание модели и ограничений применимости;
- журнал версии модели и решения;
- тесты качества по релевантным группам;
- локальное объяснение для спорного случая;
- процедура ручного пересмотра;
- владелец инцидента и срок ответа.
Источники
Техническая объяснимость, юридическое уведомление и управленческая ответственность связаны, но не заменяют друг друга. Рабочая система должна показывать всю цепочку от данных до действия.
