Объясняем предсказания вашей нейронной сети. Часть 1

В этой статье речь пойдет об интерпретируемости моделей машинного обучения, методах объяснения результатов и исследования работы моделей, а также о необходимости интерпретирования моделей как отдельной задачи. Материал является улучшенной версией теоретической части доклада How to explain predictions of your network, прочитанного на конференции AIUkraine 2018.

Зачем объяснять модель

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

Причем если построить график, где на одной оси будет отражено, насколько метод понятен человеку, как можно интерпретировать его коэффициенты, а на другой — точность указанного метода, то мы увидим следующую картину:

С одной стороны, интуитивно понятные и объяснимые методы дают малую точность, а с другой — чем мощнее метод, тем более «магической шкатулкой» он выглядит: есть множество коэффициентов, вложенных в сложную архитектуру, есть множество «магических» констант, которые или подобраны тщательным образом, или придуманы на основе общих интуитивных рассуждений. В итоге понять, как модель принимает решения, чем дальше, тем сложнее.

Однако нам, может быть, и не нужно объяснять модель? Может, лучше просто брать ту, у которой целевая метрика максимальна? Что выберете вы?

Чаще всего исследователи и практики выбирают именно максимальную целевую метрику (например, точность): это и соревнования Kaggle, и большинство реальных проектов, — при этом абсолютно не заботясь о том, чтобы метод был хоть как-либо объясним. Однако в реальной жизни есть множество областей, где нужно объяснять свое решение, обосновывать, почему программа выдает то или иное предсказание. Это и сфера медицины, и сфера финансов, и любые области, где цена ошибки слишком высока. И если вдруг клиент попросит привести доказательства эффективности вашего решения, то разговор может выглядеть примерно так:

— Почему мы должны верить вашей программе? Как вы докажете, что система работает?
— Мы взяли датасет A, архитектуру нейронной сети B, обучили ее методом C, в итоге на сете валидации мы получили значение метрики D (например, точность в 95%).
— Ну хорошо... А как ваша модель предсказывает?
— Вот архитектура сети (тут сложная картинка на страницу). Циферки со входа бегут слева направо на выход. В конце мы получаем вероятность для каждого возможного ответа, берем ответ с максимальной вероятностью.
— Допустим. А как модель сработает с такими картинками? Как модель найдет здесь собак? Что она будет для этого использовать?
— !?!
— Понятно. В production мы это пропустить не можем. Вдруг кто-нибудь из-за этого умрет? Или обратится в суд и отсудит очень много денег?

В итоге объяснить, почему модель ошиблась, что нужно сделать, чтобы она больше не ошибалась, и когда (на чем) она ошибется в следующий раз, обычно очень сложно.

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

  1. Практические:
    • Необходимость доверия пользователя к результатам модели.
    • Получение рекомендаций относительно того, как улучшить работу модели.
    • Наличие состязательных примеров (adversarial examples): например, как на картинке выше.
    • Исследование модели, получение новых знаний из модели.
  2. Социальные, регуляторные, философские...

Доверие к модели

С одной стороны, data scientist’ы привыкли к тому, что качество работы модели определяется только целевой метрикой. С другой стороны, конечным пользователям системы это все равно не дает полной уверенности в корректности работы, так как они не чувствуют и не понимают, что за этой метрикой стоит. Для того чтобы сформировать это доверие, можно идти разными способами. Например, можно:

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

Такой протокол может выглядеть следующим образом:

  • описание накладываемых ограничений;
  • описание процедуры обучения алгоритма;
  • аргументация каждого допущения в алгоритме;
  • тесты работы ML-модели в стандартных случаях;
  • описание нестандартных ситуаций в поведении модели.

Полученный протокол предоставляется заказчику — для ознакомления, анализа и подписи.

Отладка моделей

Следующая проблема — мы обучили модель, получили какой-то результат, но он нас не очень устраивает. Мы хотим улучшить его. Как нам это сделать? Обычно мы просто ищем разные сборники советов по типу «Debug моделей для чайников» и следуем такой стратегии: оптимизировать метапараметры текущей модели, изменить некоторые архитектурные блоки, если совсем ничего не получается, то попробовать другие модели или разного рода эвристики.

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

Состязательные примеры/атаки

Состязательные атаки (adversarial attack) — это очень актуальная тема, которая массово стала подниматься полтора года назад. Суть атаки состоит в том, что мы минимально меняем изначальный вход (например, изображение) таким образом, чтобы модель начала давать неправильные ответы. Например, сеть распознает изображение слева как панду всего лишь с вероятностью 57,7%. Но если наложить на изображение «белый шум» с очень маленьким весом (0,007), сеть с точностью 99,3% определит, что это гиббон.

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

Однако в ноябре 2017 года исследователи пошли еще дальше: они создали и распечатали на 3D-принтере игрушку — черепашку, которая для людей выглядела вполне нормально, а вот модель детекции объектов Google стабильно распознавала эту игрушку как винтовку.

Подробнее эксперимент можно посмотреть на видео.

Исследование модели

Следующая причина для объяснения моделей — можно ли получить новые знания из уже обученной модели. Фактически это обучение человека с помощью машинного обучения: допустим, сеть научилась делать что-то лучше нас (например, играть в го или StarCraft). Можем ли мы, в свою очередь, научиться чему-то новому у нее? Наверное, да, но для этого надо как-то извлечь эту полезную информацию из модели. Причем искать новые знания можно не только в системах для игр, то же самое мы можем попытаться сделать при исследовании сложных систем в области физики, квантовой механики и т. д.

Эти четыре причины являются основными и активно развиваются в наших реалиях. На Западе спектр понимания проблемы намного шире, глубже озабоченность проблемой. В основном это касается философской и социальной составляющих разработки моделей машинного обучения (например, смотрите недавно вышедшую статью AI Safety Needs Social Scientists).

FATE

Так, в настоящее время сформировалось понятие FATE in AI (Fairness, Accountability, Transparency, Ethics — честность, отчетность, прозрачность, этика). Это проблемы, которые требуют своего рассмотрения при разработке модели, взаимодействующей с людьми. В настоящее время этими проблемами занимаются различные коллективы в университетах и больших компаниях, например в Microsoft Research.

Под Fairness понимается следующее: действительно ли наша модель честная? Может, в ней имеется какая-либо предвзятость? Это может случиться, например, если исходная выборка составлялась и/или маркировалась с какими-либо скрытыми смещениями или предрассудками.

Пример Fairness достаточно показателен: в США существуют разные системы оценки опасности преступника, и на основании оценок этих систем судьи могут склоняться к тому или иному решению, например дать больший срок или меньший, отдать на поруки или нет. После множества странных оценок было проведено независимое расследование работы нескольких таких систем, которое показало, что среди небелых рас вероятность ошибки в два раза больше, чем для белого подсудимого. При этом раса в качестве входа модели не рассматривалась. Несмотря на исследование, найти понятное объяснение, почему так происходит, так и не удалось (подробнее — в статье).

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

Что означает интерпретация модели машинного обучения

Итак, необходимость объяснения моделей понятна, но все же что значит «проинтерпретировать модель» на практике? Что для этого нужно сделать?

Вообще, четкого ответа на этот вопрос не существует. Есть разные определения интерпретации, например такое: интерпретация модели — это процесс предоставления новой дополнительной информации, понятной человеку и достаточной для решения этим человеком последующих задач. То есть это процесс, в котором мы ориентируемся не на точность модели, не на другого робота или программу, а на таких же людей, как мы с вами. Наша задача — не понять каждый бит или каждый коэффициент системы, а предоставить дополнительную информацию, которая позволит человеку более качественно выполнить его основную задачу. Подробнее читайте в книге Interpretable Machine Learning.

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

  • Если мы объясняем модель data scientist’у, то ему нужно сообщить одну информацию. Например, он в целом и так понимает, как архитектурно выглядит модель, но не знает, какое было распределение данных, какие входные параметры оказались важными для всей системы.
  • Если мы объясняем пользователю системы, то у него другие задачи, и, соответственно, нужны другие объяснения. Например, ему будет более интересно, почему в его конкретном случае система выдала именно такой ответ, а не другой.
  • Если объяснений системы требует регулирующая организация, то им нужна будет другая информация, более полная и охватывающая множество разных ситуаций.

В формализации и развитии этих идей дальше всех продвинулась группа исследователей XAI DARPA, которая сформулировала эти идеи следующим образом: есть обучающие данные, есть некоторый процесс обучения и модель, которая решает задачу и выдает решение. Полученный результат далее используется человеком для принятия следующих решений — например, о выдаче кредита.

В DARPA предлагают параллельно с основной моделью разрабатывать другую подсистему — объясняющий интерфейс, который будет объяснять результат первой модели. Таким образом, пользователь получает не просто результат (например, вероятность), а расширенный, более глубокий ответ и может выполнять последующую задачу более качественно и осмысленно. То есть в нашем примере — не просто сказать, даем или не даем кредит, но и сразу объяснить клиенту, почему было принято это решение, конкретизировав причины выдачи/невыдачи.

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

Какие это могут быть модели? Какие модели легче поддаются интерпретации? И до каких пределов?

Простые интерпретируемые модели машинного обучения

Обычно интерпретируемыми считают следующие модели:

  • Линейные модели
  • Деревья решений
  • Некоторые нелинейные модели
  • Обобщенные аддитивные модели

Линейная модель

y = a0 + a1×1 + a2×2 + ... + anxn

  • Результат представляется в виде взвешенной суммы входных признаков.
  • Алгоритм обучения оценивает весовые коэффициенты.

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

Однако что, если переменных 1000 или 10 000? Сможем ли мы легко интерпретировать такую модель? Скорее всего, нет. Мы просто не сумеем рассмотреть каждый коэффициент, не запомним, как что влияет и как они работают вместе. В этом случае часто применяют разные методы спарсификации данных, делают отбор признаков и пытаются уменьшить размерность этой модели. Будет ли такая модель интерпретируемой? Сложно сказать. Возможно, из 1000 признаков останется только 20, и тогда модель будет понятна в целом. А может быть, останется 800 признаков, и тогда интерпретация будет затруднена.

Деревья решений

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

Возникает вопрос: насколько глубокое дерево вы сможете объяснить или понять? Если глубина дерева составляет 5 уровней, можно попробовать. А если 10? В этом случае мы имеем около 1000 правил (для бинарного дерева). А если глубина его 15 уровней, степень разбиения — не 2, а 3? Это уже проблема.

Нелинейные модели

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

Обобщенные аддитивные модели

g(y) = f1(x1) + f2(x2) + ... + fn(xn)

Эти модели также считаются сравнительно объяснимыми. В них мы складываем не взвешенные входы модели, а результаты применения некоторых нелинейных функций к входам модели. К y также обычно применяют нелинейность — логарифм, экспоненту и т. д. Считается, что эти модели тоже интерпретируемые. Например, они часто применялись в кредитном скоринге.

Однако многое ли мы сможем понять, например, из такой модели:

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

Классификация методов интерпретации моделей

Таким образом, видно, что даже самые простые и считающиеся интерпретируемыми модели не всегда могут быть легко проанализированы и не всегда прозрачны для понимания того, что там происходит... Но как тогда быть в случае с более сложными моделями? Например, для получения лучшего результата часто приходится составлять ансамбли моделей. Типичным примером таких ансамблей является алгоритм RandomForest, который 10 лет назад был одним из лучших. Можем ли мы объяснить модель, построенную по этому алгоритму? Понять, почему алгоритм выдал определенный результат? Можем ли мы провести такой же анализ для нейронной сети?

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

  • Глобальные или локальные методы
  • Моделезависимые или моделенезависмые
  • Когда производится объяснение:
    • до построения модели
    • в процессе построения модели
    • после построения модели

Глобальные vs локальные интерпретации

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

В случае глобального подхода мы вычисляем оценку важности каждого входного признака в целом для модели, например тот же importance plot для RandomForest. Или мы можем строить условные оценки важности одних признаков в зависимости от значений других. Например, если рассматривать систему постановки диагноза для пациентов, мы можем считать атрибут «кровяное давление» важным при сердечно-сосудистых заболеваниях, но в случае обычной простуды важность его снижается.

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

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

Моделезависимые и моделенезависимые подходы

Здесь методы интерпретации модели будут отличаться тем, известна и используется ли структура модели при объяснении. Примеры моделезависимых подходов:

  • Интерпретация коэффициентов в линейных моделях
  • Интерпретация на основе механизма Attention в нейронных сетях

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

Моделенезависимые (агностические) подходы подразумевают, что мы оперируем моделями, о которых не знаем практически ничего, и при интерпретации используем только их входы и выходы. На практике преимущественно такие методы и представляют из себя ценность. Примерами такого подхода являются алгоритмы LIME и Shapley. Об этих моделях я расскажу более подробно.

Интерпретируемость до построения модели

Мы можем озаботиться вопросом интерпретации еще на самых ранних этапах составления модели, например еще до этапа выбора алгоритма машинного обучения, то есть фактически на этапе Exploratory Data Analysis. Мы можем попытаться понять распределение данных, на какие кластеры они распадаются или какие признаки являются важными.

Интерпретируемость во время составления модели

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

  • Линейные модели
  • Разреженные модели
  • Подходы, основанные на правилах (деревья решений)
  • Монотонные модели (монотонные ограничения, например в XGBoost)
  • Attention-механизм в нейронных сетях

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

Есть еще одно направление — построение монотонных моделей, когда модель выдает монотонный ответ в зависимости от тех или иных признаков. Например, в XGBoost уже встроены такие механизмы. Мало кто о них знает, но иногда это помогает улучшать качество этих моделей.

Как пример, есть еще один интересный подход: исследователи пытались реализовать автоматическое добавление подписи к изображениям (Image Captioning) и построили более сложную модель, которая выдает не только подпись к картинке, но и объяснение, почему она описала картинку тем или иным образом. Фактически они построили две модели (рекуррентные сети): одна выдает описание картинки, вторая — разъяснение этого описания. Фактически это реализация идеи XAI DARPA про объясняющий интерфейс.

This is a Kentucky warbler because this is a yellow bird with a black cheek patch and a black crown.

Это кентуккский масковый певун: птица имеет желтый окрас перьев, черные пятна на щеках и черный хохолок.

Интерпретируемость после составления модели

Более интересный и, наверное, максимально востребованный подход — исследование и попытка интерпретации некоторого «черного ящика». Речь идет о предобученных нейронных сетях, моделях Support Vector Machines, ансамблях и т. д.

Здесь возможны сразу три задачи:

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

Объяснение модели

По факту данный метод занимается вычленением правил из моделей и в целом похож на Model Distillation, только при условии, что полученная модель должна быть не меньшего размера, а максимально интерпретируемой. Например, в 2017 году команда Google Brain выпустила статью Distilling a Neural Network Into a Soft Decision Tree, где конволюционная сеть приближается небольшим деревом решений.

Объяснение результата

В данных методах мы ищем, какие входные переменные сильнее всего повлияли на результат. Например, на какие части изображения преимущественно «смотрела» нейронная сеть при распознавании картинки. Мы можем визуализировать, реально модель «смотрит» на объект при распознавании или же центральная часть изображения вообще не интересна сети и основной вклад в результат приносят крайние пиксели (чаще всего фон).

Типичными примерами таких методов являются:

  • Маски чувствительности (Saliency maps)
  • Алгоритм LIME
  • SHAPley-коэффициенты

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

Внутреннее исследование «черного ящика»

Здесь мы решаем примерно ту же задачу, что и при объяснении выхода, но не для последнего слоя, а для внутренних слоев. Мы пытаемся объяснить, что делает каждый конкретный слой внутри сети. Например, для этих целей мы можем использовать библиотеку Lucid, которая разрабатывается в Google (смотрите статьи Feature Visualization и The Building Blocks of Interpretability).

Заключение

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

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

  • Формального определения объяснения модели не существует, то есть объяснения для разных моделей и для разных реципиентов будут различными.
  • Мы не можем выразить качество объяснения численно, например: «Это объяснение хорошее, его показатель 90%, а это чуть хуже, его показатель 85%». Пока таких метрик нет. Есть очень сложные подходы, сложные фреймворки по постановке таких экспериментов, но на практике они очень трудны для воспроизведения.
  • Непонятно, сколько времени занимает понимание объяснения модели. Иногда это может происходить быстро, а иногда для понимания модели нужно воспроизвести все вычисления, происходящие в модели.
  • Не всегда понятны цели обучения. Для кого создается объяснение? Для data scientist’ов, владельцев бизнеса, конечного пользователя?
  • Что делать с конфликтующими объяснениями?

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

Также в последнее время появилось множество различных библиотек для объяснения моделей. Недавно вышла статья о новом фреймворке Google для объяснения моделей работы нейронных сетей What-if. IBM только недавно подключилась к этой гонке с фреймворком Fairness 360 Kit.

Полезные ссылки:

Похожие статьи:
Щомісяця ми дивимося, що відбувалося на jobs.dou.ua з вакансіями, відгуками та компаніями. Найцікавіше у лютому:4,5 тисячі вакансій —...
SQLSaturday Kyiv пройдёт в Киеве (да, знаю, неожиданно :)) 20 мая. Дмитрий Пилюгин снова начал вести свой крутой русскоязычный блог. Пол...
Більше ніж п’ять років я займаюся мобільною розробкою, останні два роки на позиції Tech Lead у Symphony Solutions. У вільний час...
В этой статье я попытаюсь рассказать про принцип инверсии зависимостей (Dependency inversion principle, далее DIP). В статье будут...
По результатам опроса на DOU, средний возраст украинских IT-специалистов — 27 лет, а доля сотрудников, старше 40 лет,...
Яндекс.Метрика