Copyright 2019 The TensorFlow Authors.

La API funcional "Keras" en TensorFlow

Note: Nuestra comunidad de Tensorflow ha traducido estos documentos. Como las traducciones de la comunidad son basados en el "mejor esfuerzo", no hay ninguna garantia que esta sea un reflejo preciso y actual de la Documentacion Oficial en Ingles. Si tienen sugerencias sobre como mejorar esta traduccion, por favor envian un "Pull request" al siguiente repositorio tensorflow/docs. Para ofrecerse como voluntario o hacer revision de las traducciones de la Comunidad por favor contacten al siguiente grupo docs@tensorflow.org list.

Setup

Introduccion

Ya estás familiarizado con el uso del metodo keras.Sequential() para crear modelos. La API funcional es una forma de crear modelos mas dinamicos que con Sequential: La API funcional puede manejar modelos con topología no lineal, modelos con capas compartidas y modelos con múltiples entradas o salidas.

Se basa en la idea de que un modelo de aprendizaje profundo suele ser un gráfico acíclico dirigido (DAG) de capas. La API funcional es un conjunto de herramientas para construir gráficos de capas.

Considera el siguiente modelo:

(input: 784-vectores dimensionales)
       ↧
[Dense (64 units, activacion relu)]
       ↧
[Dense (64 units, activacion relu)]
       ↧
[Dense (10 units, activacion softmax)]
       ↧
(output: distribución de probabilidad en 10 clases)

Es una simple grafica de tres capas.

Para construir este modelo con la API funcional, comenzarías creando un nodo de entrada:

Aqui solo especificamos el tipo de nuestra data set: 784-vectores dimensionales. Nota que el tamaño del batch siempre debe ser omitido, solo se incluye el tipo de la data set. Para una input de tipo imágen (31,32,3) hubiese sido:

Lo que se devuelve, input, contiene información sobre la forma y el tipo de dato que se espera ingresa en tu modelo:

Puedes crear un nuevo nodo en el grafico de capas mandando a llamar al objeto input.

La acción "layer call" es como dibujar una flecha desde "entradas" a la capa que creamos. Estamos "pasando" las entradas a la capa dense, y afuera obtenemosx.

Agreguemos algunas capas más a nuestro gráfico de capas:

La acción "llamada a la capa" es como dibujar una flecha de "entradas" a la capa que creamos.

Estamos pasando las entradas a una capa mas densa, y respecto a la salida obtenemos una x.

LLegados a este punto, podemos crear un Modelo especificando sus entradas y salidas en las capas de graficas.

Recapitulando, esta es nuestra definción completa del proceso:

Veamos como se muestra el model summary:

También podemos trazar el modelo como un gráfico:

Y opcionalmente mostrar la entrada y la salida de la forma de cada capa en la gráfica ploteada:

Esta figura y el código que escribimos son prácticamente idénticos. En la versión de código, las flechas de conexión simplemente se reemplazan por la operación de llamada.

Un "gráfico de capas" es una imagen mental muy intuitiva para un modelo de aprendizaje profundo, y la API funcional es una forma de crear modelos que reflejan de cerca esta imagen mental.

Entrenamiento, evaluación e inferencia.

El entrenamiento, la evaluación y la inferencia funcionan exactamente de la misma manera para los modelos construidos utilizando la API funcional como para los modelos secuenciales.

Aquí hay una demostración rápida.

Aquí cargamos datos de imagen MNIST, los rediseñamos en vectores, ajustar el modelo en los datos (mientras se monitorea el rendimiento en una división de validación), y finalmente evaluamos nuestro modelo en los datos de prueba:

Para obtener una guía completa sobre el entrenamiento y evaluación de modelos, consulta Guía de entrenamiento y evaluación.

Almacenado y serialización

El almacenado y la serialización funcionan exactamente de la misma manera para los modelos construidos utilizando la API funcional como para los modelos secuenciales.

Una forma estándar de guardar un modelo funcional es llamar a model.save () para guardar todo el modelo en un solo archivo. Posteriormente, puede volver a crear el mismo modelo a partir de este archivo, incluso si ya no tiene acceso al código. eso creó el modelo.

Este archivo incluye:

• La arquitectura del modelo.
• Los valores de peso del modelo (que se aprendieron durante el entrenamiento)
• La configuración de entrenamiento del modelo (lo que pasó a compilar), si corresponde
• El optimizador y su estado, si corresponde (esto le permite reiniciar el entrenamiento donde lo dejó)

Para obtener una guía completa sobre el guardado de modelos, consulta Guía para guardar y serializar modelos.

Usando el mismo gráfico de capas para definir múltiples modelos

En la API funcional, los modelos se crean especificando sus entradas y salidas en un gráfico de capas. Eso significa que un solo gráfico de capas Se puede utilizar para generar múltiples modelos.

En el siguiente ejemplo, usamos la misma arquitectura de capas para crear instancias de dos modelos: un modelo de "codificador" que convierte las entradas de imagen en vectores de 16 dimensiones, y un modelo completo de autoencoder para entrenamiento.

Tenga en cuenta que hacemos que la arquitectura de decodificación sea estrictamente simétrica a la arquitectura de codificación, para que obtengamos una forma de salida que sea igual a la forma de entrada (28, 28, 1). El reverso de una capa Conv2D es una capaConv2DTranspose, y el reverso de una capa MaxPooling2D La capa es una capa UpSampling2D.

Todos los modelos son invocables, al igual que las capas.

Puede tratar cualquier modelo como si fuera una capa, llamándolo en una Entrada o en la salida de otra capa. Tenga en cuenta que al llamar a un modelo no solo está reutilizando la arquitectura del modelo, también está reutilizando sus pesos.

Veamos esto en acción. Aquí hay una versión diferente del ejemplo de autoencoder que crea un modelo de codificador, un modelo de decodificador, y encadenarlos en dos llamadas para obtener el modelo de autoencoder:

Como puede ver, el modelo puede estar anidado: un modelo puede contener submodelos (ya que un modelo es como una capa).

Un caso de uso común para la anidación de modelos es ensamblaje . Como ejemplo, a continuación se explica cómo agrupar un conjunto de modelos en un solo modelo que promedia sus predicciones:

Manipulación de topologías gráficas complejas

Modelos con múltiples entradas y salidas

La API funcional facilita la manipulación de múltiples entradas y salidas. Esto no se puede manejar con la API secuencial.

Aquí hay un ejemplo simple.

Supongamos que está creando un sistema para clasificar los tickets de emisión personalizados por prioridad y enrutarlos al departamento correcto.

Tu modelo tendrá 3 entradas:

• Título del ticket (entrada de texto)
• Cuerpo del texto del ticket (entrada de texto)
• Cualquier etiqueta agregada por el usuario (entrada categórica)

Tendrá dos salidas:

• Puntuación de prioridad entre 0 y 1 (salida sigmoidea escalar)
• El departamento que debe manejar el ticket (salida softmax sobre el conjunto de departamentos)

Construyamos este modelo en pocas líneas con la API funcional.

Ploteando el modelo:

Al compilar este modelo, podemos asignar diferentes pérdidas a cada salida. Incluso puede asignar diferentes pesos a cada pérdida, para modular su contribución a la pérdida total de entrenamiento.

Como dimos nombres a nuestras capas de salida, también podríamos especificar la pérdida de esta manera:

Podemos entrenar el modelo pasando listas de matrices Numpy de entradas y objetivos:

Al llamar al ajuste con un objeto Dataset, debería producir un tupla de listas como ([title_data, body_data, tags_data], [priority_targets, dept_targets]) o una tupla de diccionarios como ({'title': title_data, 'body': body_data, 'tags': tags_data}, {'priority': priority_targets, 'department': dept_targets}).

Para obtener una explicación más detallada, consulta la guía completa Guía de entrenamiento y evaluación.

Un modelo de Red neuronal residual de juguete

Además de los modelos con múltiples entradas y salidas, La API funcional facilita la manipulación de topologías de conectividad no lineal, es decir, modelos donde las capas no están conectadas secuencialmente. Esto tampoco se puede manejar con la API secuencial (como su nombre lo indica).

Un caso de uso común para esto son las conexiones residuales.

Construyamos un modelo de ResNet de juguete para CIFAR10 para demostrar esto.

Ploteando el modelo:

Vamos a entrenarlo:

Compartir capas

Otro buen uso de la API funcional son los modelos que usan capas compartidas. Las capas compartidas son instancias de capa que se reutilizan varias veces en un mismo modelo: aprenden características que corresponden a múltiples rutas en el gráfico de capas.

Las capas compartidas a menudo se usan para codificar entradas que provienen de espacios similares (por ejemplo, dos piezas de texto diferentes que presentan un vocabulario similar), ya que permiten compartir información entre estas diferentes entradas y hacen posible entrenar un modelo de este tipo en menos datos. Si se ve una palabra determinada en una de las entradas, eso beneficiará el procesamiento de todas las entradas que pasan por la capa compartida.

Para compartir una capa en la API funcional, simplemente llame a la misma instancia de capa varias veces. Por ejemplo, aquí hay una capa Ingresa (del ingles Embedding) compartida entre dos entradas de texto diferentes:

Extracción y reutilización de nodos en el gráfico de capas

Debido a que el gráfico de capas que está manipulando en la API funcional es una estructura de datos estática, se puede acceder e inspeccionarlo. Así es como podemos trazar modelos funcionales como imágenes, por ejemplo.

Esto también significa que podemos acceder a las activaciones de capas intermedias ("nodos" en el gráfico) y reutilizarlas en otros lugares. ¡Esto es extremadamente útil para la extracción de características, por ejemplo!

Veamos un ejemplo. Este es un modelo VGG19 con pesas pre-entrenadas en ImageNet:

Y estas son las activaciones intermedias del modelo, obtenidas al consultar la estructura de datos del gráfico:

Podemos usar estas características para crear un nuevo modelo de extracción de características, que devuelve los valores de las activaciones de la capa intermedia, y podemos hacer todo esto en 3 líneas.

Esto es útil cuando [implementa la transferencia de estilo neural] (https://medium.com/tensorflow/neural-style-transfer-creating-art-with-deep-learning-using-tf-keras-and-eager-execution- 7d541ac31398), entre otras cosas.

Extendiendo la API escribiendo capas personalizadas

tf.keras tiene una amplia gama de capas incorporadas. Aquí están algunos ejemplos:

• Capas convolucionales: Conv1D,Conv2D, Conv3D,Conv2DTranspose, etc.
• Capas de agrupación: MaxPooling1D,MaxPooling2D, MaxPooling3D,AveragePooling1D, etc.
• Capas RNN: GRU,LSTM, ConvLSTM2D, etc.
• BatchNormalization,Dropout, Embedded, etc.

Si no encuentras lo que necesitas, es fácil extender la API creando tus propias capas.

Todas las capas subclasifican la clase Layer e implementan:

• Un método call, que especifica el cálculo realizado por la capa.
• Un método build, que crea los pesos de la capa (tenga en cuenta que esto es solo una convención de estilo; también puede crear pesos en__init__).

Para obtener más información sobre cómo crear capas desde cero, consulta la guía Guía para escribir capas y modelos desde cero.

Aquí hay una implementación simple de una capa Densa:

Si deseas que tu capa personalizada admita la serialización, también debes definir un método get_config, que devuelve los argumentos del constructor de la instancia de capa:

Opcionalmente, también podría implementar el método de clase from_config (cls, config), que se encarga de recrear una instancia de capa dado su diccionario de configuración. La implementación predeterminada de from_config es:

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

Cuándo usar la API funcional

¿Cómo decidir si usar la API funcional para crear un nuevo modelo o simplemente subclasificar la clase Modelo directamente?

En general, la API funcional es de nivel superior, más fácil y segura de usar, y tiene una serie de características que los modelos de subclases no admiten.

Sin embargo, la subclasificación de modelos le brinda una mayor flexibilidad al crear modelos que no se pueden expresar fácilmente como gráficos acíclicos dirigidos de capas (por ejemplo, no podría implementar un Tree-RNN con la API funcional, tendría que subclasificar Model directamente).

Estas son las fortalezas de la API funcional:

Las propiedades enumeradas a continuación también son ciertas para los modelos secuenciales (que también son estructuras de datos), pero no son ciertas para los modelos subclasificados (que son bytecode de Python, no estructuras de datos).

Es menos detallado.

No super (MyClass, self) .__ init __ (...), no def call (self, ...):, etc.

Comparar:

pitón
input = keras.Input (shape = (32,))
x = capas. Denso (64, activación = 'relu') (entradas)
salidas = capas. Denso (10) (x)
mlp = keras.Model (entradas, salidas)

Con la versión subclaseada:

pitón
clase MLP (keras.Model):

  def __init __ (self, ** kwargs):
    super (MLP, self) .__ init __ (** kwargs)
    self.dense_1 = capas.Dense (64, activación = 'relu')
    self.dense_2 = layers.Dense (10)

  llamada def (auto, entradas):
    x = self.dense_1 (entradas)
    return self.dense_2 (x)

# Instanciar el modelo.
mlp = MLP ()
# Necesario para crear el estado del modelo.
# El modelo no tiene un estado hasta que se llama al menos una vez.
_ = mlp (tf.zeros ((1, 32)))

Valida su modelo mientras lo está definiendo.

En la API funcional, su especificación de entrada (forma y dtype) se crea de antemano (a través de Input), y cada vez que llama a una capa, la capa comprueba que la especificación que se le pasa coincide con sus supuestos, y generará un mensaje de error útil si no.

Esto garantiza que se ejecutará cualquier modelo que pueda construir con la API funcional. Toda la depuración (que no sea la depuración relacionada con la convergencia) ocurrirá estáticamente durante la construcción del modelo, y no en el momento de la ejecución. Esto es similar a la comprobación de tipo en un compilador.

Tu modelo funcional es trazable e inspeccionable.

Puedes trazar el modelo como un gráfico, y puedes acceder fácilmente a los nodos intermedios en este gráfico, por ejemplo, para extraer y reutilizar las activaciones de las capas intermedias, como vimos en un ejemplo anterior:

pitón
features_list = [layer.output para la capa en vgg19.layers]
feat_extraction_model = keras.Model (input = vgg19.input, salidas = features_list)

Su modelo funcional puede ser serializado o clonado.

Debido a que un modelo funcional es una estructura de datos en lugar de un fragmento de código, es serializable de forma segura y se puede guardar como un único archivo que le permite recrear exactamente el mismo modelo sin tener acceso a ninguno de los códigos originales. Consulta nuestra [guía de guardado y serialización] (./save_and_serialize.ipynb) para obtener más detalles.

Estas son las debilidades de la API funcional:

No admite arquitecturas dinámicas.

La API funcional trata los modelos como DAG de capas. Esto es cierto para la mayoría de las arquitecturas de aprendizaje profundo, pero no para todas: por ejemplo, las redes recursivas o los RNN de árbol no siguen este supuesto y no se pueden implementar en la API funcional.

A veces, solo necesitas escribir todo desde cero.

Al escribir actividades avanzadas, es posible que desee hacer cosas que están fuera del alcance de "definir un DAG de capas": por ejemplo, es posible que desee exponer múltiples métodos personalizados de entrenamiento e inferencia en su instancia de modelo. Esto requiere subclases.

Para profundizar más en las diferencias entre la API funcional y la subclasificación de modelos, puede leer [¿Qué son las API simbólicas e imperativas en TensorFlow 2.0?] (Https://medium.com/tensorflow/what-are-symbolic-and -imperative-apis-in-tensorflow-2-0-dfccecb01021).

Mezcla y combina diferentes estilos de API

Es importante destacar que elegir entre la subclasificación de API funcional o modelo no es una decisión binaria que lo restringe a una categoría de modelos. Todos los modelos en la API tf.keras pueden interactuar con cada uno, ya sean modelos secuenciales, modelos funcionales o modelos / capas subclasificados escritos desde cero.

Siempre puede usar un modelo funcional o modelo secuencial como parte de un modelo / capa subclasificado:

Inversamente, puede usar cualquier Capa o Modelo subclasificado en la API Funcional siempre que implemente un método call que siga uno de los siguientes patrones:

• call (self, input, ** kwargs) donde input es un tensor o una estructura anidada de tensores (por ejemplo, una lista de tensores), y donde** kwargs son argumentos no tensoriales (no input )
• call (self, input, training = None, ** kwargs) donde training es un valor booleano que indica si la capa debe comportarse en modo de entrenamiento y modo de inferencia.
• call (self, input, mask = None, ** kwargs) donde mask es un tensor de máscara booleano (útil para RNN, por ejemplo).
• call (self, input, training = None, mask = None, ** kwargs) - por supuesto, puede tener tanto un comportamiento específico de enmascaramiento como de entrenamiento al mismo tiempo.

Además, si implementa el método get_config en su Capa o Modelo personalizado, los modelos funcionales que cree con él seguirán siendo serializables y clonables.

Aquí hay un ejemplo rápido en el que usamos un RNN personalizado escrito desde cero en un modelo funcional:

¡Esto concluye nuestra guía sobre la API funcional "Keras"!

Ahora tienes a tu alcance un poderoso conjunto de herramientas para construir modelos de aprendizaje profundo.