Copyright 2019 The TensorFlow Authors.

Keras functional API в TensorFlow

Note: Вся информация в этом разделе переведена с помощью русскоговорящего Tensorflow сообщества на общественных началах. Поскольку этот перевод не является официальным, мы не гарантируем что он на 100% аккуратен и соответствует официальной документации на английском языке. Если у вас есть предложение как исправить этот перевод, мы будем очень рады увидеть pull request в tensorflow/docs репозиторий GitHub. Если вы хотите помочь сделать документацию по Tensorflow лучше (сделать сам перевод или проверить перевод подготовленный кем-то другим), напишите нам на docs-ru@tensorflow.org list.

Setup

Введение

Вы уже знакомы с использованием keras.Sequential() для создания моделей. Functional API позволяет создавать модели более гибко чем Sequential: он может обрабатывать модели с нелинейной топологией, модели с общими слоями, и модели с несколькими входами или выходами.

Он основан на том, что модель глубоко обучения обычно представляет собой ориентированный ациклический граф (DAG) слоев. Functional API - это набор инструментов для построения графа слоев.

Рассмотрим следующую модель:

(вход: 784-мерный вектор)
       ↧
[Плотный слой (64 элемента, активация relu)]
       ↧
[Плотный слой (64 элемента, активация relu)]
       ↧
[Плотный слой (10 элементов, активация softmax)]
       ↧
(выход: вероятностное распределение на 10 классов)

Это простой граф из 3 слоев.

Для построения этой модели с помощью functional API, вам надо начать с создания входного узла:

Здесь мы просто указываем размерность наших данных: 784-мерных векторов. Обратите внимание, что количество данных всегда опускается, мы указываем только размерность каждого элемента. Для ввода предназначенного для изображений размеров (32, 32, 3), мы бы использовали:

То, что возвращает inputs, содержит информацию о размерах и типе данных которые вы планируете передать в вашу модель:

Вы создаете новый узел в графе слоев, вызывая слой на этом объекте inputs:

"Вызов слоя" аналогичен рисованию стрелки из "входных данных" в созданный нами слой. Мы "передаем" входные данные в dense слой, и мы получаем x.

Давайте добавим еще несколько слоев в наш граф слоев:

Сейчас мы можем создать Model указав его входы и выходы в графе слоев:

Напомним полный процесс определения модели:

Давайте посмотрим как выглядит сводка модели:

Мы также можем начертить модель в виде графа:

И опционально выведем размерности входа и выхода каждого слоя на построенном графе:

Это изображение и код который мы написали идентичны. В версии кода, связывающие стрелки просто заменены операциями вызова.

"Граф слоев" это очень интуитивный ментальный образ для модели глубокого обучения, а functional API это способ создания моделей которые близко отражают этот ментальный образ.

Обучение, оценка и вывод

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

Вот быстрая демонстрация.

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

Полное руководство посвященное обучению и оценки моделей, см. по ссылке руководство обучения и оценки.

Сохранение и сериализация

Сохранение и сериализация для моделей построенных с использованием Functional API работает точно так же как и для Sequential моделей.

Стандартным способом сохранения Functional модели является вызов model.save() позволяющий сохранить всю модель в один файл. Позже вы можете восстановить ту же модель из этого файла, даже если у вас больше нет доступа к коду создавшему модель.

Этот файл включает:

• Архитектуру модели
• Значения весов модели (которые были получены во время обучения)
• Конфигурация обучения модели (то что вы передавали в compile)
• Оптимизатор и его состояние, если оно было (это позволяет возобновить обучение с того места, где вы остановились)

Полное руководство по сохранению моделей см. в Руководство по сохранению и сериализации моделей.

Использование одного и того же графа слоев для определения нескольких моделей

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

В приведенном ниже примере мы используем один и тот же стек слоев для создания двух моделей: модель кодировщика (encoder) которая преобразует входные изображения в 16-мерные вектора, и сквозную модель автокодировщика (autoencoder) для обучения.

Обратите внимание, что мы делаем архитектуру декодирования строго симметричной архитектуре кодирования, так что мы получим размерность выходных данных такую же как и входных данных (28, 28, 1). Обратным к слою Conv2D является слой Conv2DTranspose, а обратным к слою MaxPooling2D будет слой UpSampling2D.

Модели можно вызывать как слои

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

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

Как вы видите, модель может быть вложена: модель может содержать подмодель (поскольку модель можно рассматривать как слой).

Распространенным вариантом использования вложения моделей является ensembling. В качестве примера, вот как можно объединить набор моделей в одну модель которая усредняет их прогнозы:

Манипулирование сложными топологиями графов

Модели с несколькими входами и выходами

Functional API упрощает манипуляции с несколькими входами и выходами. Это не может быть сделано с Sequential API.

Вот простой пример.

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

У вашей модели будет 3 входа:

• Заголовок заявки (текстовые входные данные)
• Текстовое содержание заявки (текстовые входные данные)
• Любые теги добавленные пользователем (категорийные входные данные)

У модели будет 2 выхода:

• Оценка приоритета между 0 и 1 (скаляр, результат сигмоидного выхода)
• Отдел который должен обработать заявку (softmax выход относительно множества отделов)

Давайте построим модель в несколько строк с помощью Functional API.

Давайте начертим граф модели:

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

Так как мы дали имена нашим выходным слоям, мы можем также указать функции потерь:

Мы можем обучить модель передавая списки массивов Numpy входных данных и меток:

При вызове fit с объектом Dataset, должны возвращаться либо кортеж списков, таких как ([title_data, body_data, tags_data], [priority_targets, dept_targets]) либо кортеж словарей ({'title': title_data, 'body': body_data, 'tags': tags_data}, {'priority': priority_targets, 'department': dept_targets}).

Для более подробного объяснения обратитесь к полному руководству руководство по обучению и оценке.

Учебная resnet модель

В дополнение к моделям с несколькими входами и выходами, Functional API упрощает манипулирование топологиями с нелинейной связностью, то есть моделями, в которых слои не связаны последовательно. Это также не может быть реализовано с помощью Sequential API (это видно из названия).

Распространенный пример использования этого - residual connections.

Давайте построим учебную ResNet модель для CIFAR10 чтобы продемонстрировать это.

Давайте начертим модель:

Давайте обучим ее:

Совместное использование слоев

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

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

Чтобы совместно использовать слой в Functional API, просто вызовите тот же экземпляр слоя несколько раз. Например, здесь слой Embedding используется совместно на двух текстовых входах:

Извлечение и повторное использование узлов в графе слоев

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

Это также означает, что мы можем получить доступ к активациям промежуточных слоев ("узлов" в графе) и использовать их в других местах. Это чрезвычайно полезно для извлечения признаков, например!

Давайте посмотрим пример. Это модель VGG19 с весами предобученными на ImageNet:

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

Мы можем использовать эти признаки для создания новой модели извлечения признаков, которая возвращает значения активаций промежуточного уровня - и мы можем сделать все это в 3 строчки

Это удобно когда реализуется neural style transfer, как и в других случаях.

Расширение API при помощи написания кастомных слоев

tf.keras обладает широким набором встроенных слоев. Вот несколько примеров:

• Сверточные слои: Conv1D, Conv2D, Conv3D, Conv2DTranspose, и т.д.
• Слои пулинга: MaxPooling1D, MaxPooling2D, MaxPooling3D, AveragePooling1D, и т.д.
• Слои RNN: GRU, LSTM, ConvLSTM2D, и т.д.
• BatchNormalization, Dropout, Embedding, и т.д.

Если вы не нашли то, что вам нужно, легко расширить API создав собственный слой.

Все слои сабклассируют класс Layer и реализуют:

• Метод call, определяющий вычисления выполняемые слоем.
• Метод build, создающий веса слоя (заметим что это всего лишь стилевое соглашение; вы можете также создать веса в __init__).

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

Вот простая реализация Dense слоя:

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

Опционально, вы также можете реализовать метод класса from_config (cls, config), который отвечает за пересоздание экземпляра слоя, учитывая его словарь конфигурации. Реализация по умолчаниюfrom_config выглядит так:

def from_config(cls, config):
  return cls(**config)

Когда использовать Functional API

Как определить когда лучше использовать Functional API для создания новой модели, или просто сабклассировать класс Model напрямую?

В целом, Functional API более высокоуровневый и простой в использовании, он имеет ряд функций, которые не поддерживаются сабклассированными Model.

Однако, сабклассирование Model дает вам большую гибкость при создании моделей, которые не описываются легко в виде направленного ациклического графа слоев (например, вы не сможете реализовать Tree-RNN с Functional API, вам нужно сабклассировать напрямую Model).

Cильные стороны Functional API:

Свойства перечисленные ниже являются все верными и для Sequential моделей (которые также являются структурами данных), но они верны для сабклассированных моделей (которые представляют собой код Python, а не структуры данных).

С Functional API получается более короткий код.

Нет super(MyClass, self).__init__(...), нет def call(self, ...):, и т.д.

Сравните:

inputs = keras.Input(shape=(32,))
x = layers.Dense(64, activation='relu')(inputs)
outputs = layers.Dense(10)(x)
mlp = keras.Model(inputs, outputs)

С сабклассированной версией:

class MLP(keras.Model):

  def __init__(self, **kwargs):
    super(MLP, self).__init__(**kwargs)
    self.dense_1 = layers.Dense(64, activation='relu')
    self.dense_2 = layers.Dense(10)

  def call(self, inputs):
    x = self.dense_1(inputs)
    return self.dense_2(x)

# Создадим экземпляр модели.
mlp = MLP()
# Необходимо создать состояние модели.
# У модели нет состояния пока она не была вызвана хотя бы раз.
_ = mlp(tf.zeros((1, 32)))

Он валидирует вашу модель пока вы ее определяете.

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

Это гарантирует, что любая модель которую вы построите с Functional API запустится. Вся отладка (не относящаяся к отладке сходимости) будет происходить статично во время конструирования модели, а не во время выполнения. Это аналогично проверке типа в компиляторе.

Вашу Functional модель можно представить графически, а также она проверяема.

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

features_list = [layer.output for layer in vgg19.layers]
feat_extraction_model = keras.Model(inputs=vgg19.input, outputs=features_list)

Ваша Functional модель может быть сериализована или клонирована.

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

Слабые стороны Functional API:

Он не поддерживает динамичные архитектуры.

Functional API обрабатывает модели как DAG слоев. Это справедливо для большинства архитектур глубокого обучения, но не для всех: например, рекурсивные сети или Tree RNN не соответствуют этому предположению и не могут быть реализованы в Functional API.

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

При написании продвинутых архитектур вы можете захотеть сделать то, что выходит за рамки "определения DAG слоев": например, вы можете использовать несколько пользовательских методов обучения и вывода на экземпляре вашей модели. Это требует сабклассирования.

Чтобы глубже погрузиться в разницу между Functional API и сабклассированием Model, вы можете прочитать Что такое Symbolic и Imperative API в TensorFlow 2.0?.

Сочетание различных стилей API

Важно отметить, что выбор между Functional API или сабклассированием Model не является бинарным решением, которое ограничивает вас одной категорией моделей. Все модели в API tf.keras могут взаимодействовать друг с другом, будь то Sequential модели, Functional модели или сабклассированные Models/Layers, написанные с нуля.

Вы всегда можете использовать Functional модель или Sequential модель как часть сабклассированного Model/Layer:

Обратно, вы можете использовать любой сабклассированный Layer или Model в Functional API в том случае если реализован метод call который соответствует одному из следующих паттернов:

• call(self, inputs, **kwargs) где inputs это тензор или вложенная струтура тензоров (напр. список тензоров), и где **kwargs это нетензорные аргументы (не входные данные).
• call(self, inputs, training=None, **kwargs) где training это булево значение показывающее в каком режиме должен вести себя слой, обучения или вывода.
• call(self, inputs, mask=None, **kwargs) где mask это тензор булевой маски (полезно для RNN, например).
• call(self, inputs, training=None, mask=None, **kwargs) -- конечно вы можете иметь одновременно оба параметра определяющих поведение слоя.

В дополнение, если вы реализуете метод get_config на вашем пользовательском Layer или Model, Functional модели которые вы создадите с ним будут сериализуемы и клонируемы.

Далее приведем небольшой пример где мы используем кастомный RNN написанный с нуля Functional модели:

Это завершает наше руководство по Functional API!

Теперь у вас под рукой мощный набор инструментов для построения моделей глубокого обучения.