Descripción general de la predicción

Puedes alojar los modelos de aprendizaje automático entrenados en la nube y usar el servicio de predicción de Cloud ML para inferir los valores objetivo de datos nuevos. En esta página, se analizan el alojamiento de modelos y la predicción, y se presentan consideraciones que debes tener en cuenta para tus proyectos.

Cómo funciona

El servicio de predicción de Cloud ML Engine administra recursos de procesamiento en la nube para ejecutar tus modelos. Puedes solicitar predicciones a tus modelos y obtener valores objetivo previstos para ellos. Este es el proceso de preparación para realizar predicciones en la nube:

  1. Exportas tu modelo usando modelo guardado como parte de tu aplicación de entrenamiento.

  2. Creas un recurso de modelo en Cloud ML Engine y luego una versión del modelo a partir del modelo guardado.

  3. Le das formato a tus datos de entrada para la predicción y solicitas la predicción en línea o por lotes.

  4. Cuando usas la predicción en línea, el servicio ejecuta tu modelo guardado y muestra las predicciones solicitadas como mensaje de respuesta a la llamada.

    • Tu versión del modelo se implementa en la región que especificaste cuando creaste el modelo.
    • Aunque no está garantizado, se suele tener lista para ejecutar una versión del modelo que usas regularmente.

    Cuando usas la predicción por lotes, el proceso es un poco más complejo:

    1. El servicio de predicción asigna recursos para ejecutar tu trabajo. Esto incluye uno o más nodos de predicción.

    2. El servicio restablece tu grafo de TensorFlow en cada nodo asignado.

    3. El servicio de predicción distribuye tus datos de entrada en todos los nodos asignados.

    4. Cada nodo ejecuta tu grafo y guarda las predicciones en una ubicación de Google Cloud Storage que especifiques.

    5. Una vez procesados todos los datos de entrada, el servicio cierra el trabajo y libera los recursos que le asignó.

Implementación del modelo

Cloud ML Engine puede alojar tus modelos para que puedas obtener predicciones de ellos en la nube. El proceso de alojar un modelo guardado se llama implementación. El servicio de predicción administra la infraestructura necesaria para ejecutar tu modelo a gran escala y lo pone a disposición de las solicitudes de predicción en línea y por lotes. En esta sección, se describe la implementación del modelo.

Acerca de modelos y versiones

Cloud ML Engine organiza tus modelos entrenados con recursos llamados modelos y versiones. Un modelo es una solución de aprendizaje automático. Por ejemplo, puedes crear un modelo llamado census que contenga todo tu trabajo en un modelo de aprendizaje automático del censo de EE.UU. La entidad que creas, llamada census, es un contenedor de las implementaciones reales del modelo de aprendizaje automático, que se llaman versiones.

El proceso de desarrollo de un modelo de aprendizaje automático es iterativo. Por tal motivo, el paradigma de recursos de Cloud ML Engine se configura suponiendo que crearás varias versiones de cada modelo de aprendizaje automático. Esta terminología puede ser confusa debido a que un recurso de modelo de Cloud ML Engine no es en realidad un modelo de aprendizaje automático por sí mismo. En Cloud ML Engine, un modelo es un contenedor de las versiones del modelo de aprendizaje automático.

¿Qué se incluye en una versión?

El “modelo” que implementas en Cloud ML Engine como versión del modelo es un modelo guardado de TensorFlow. Exportas un modelo guardado en tu entrenador. Es indistinto si entrenaste tu modelo en la nube usando Cloud ML Engine o en otro lugar, siempre y cuando tengas un modelo guardado con la firma de entrega configurada como serving_default.

Variaciones entre versiones

Las versiones que crees de cualquier modelo dado son arbitrarias; puedes usar el mismo recurso de modelo incluso si cambias por completo el modelo de aprendizaje automático entre versiones. Un modelo es una herramienta organizativa que puedes usar de cualquier modo que tenga sentido en tu caso.

Es común, en especial luego de tener una versión en producción, mantener iguales las entradas y salidas entre las versiones del modelo. Esto te permite cambiar de versión sin necesidad de modificar otra estructura de la aplicación que puedas haber compilado en torno al modelo. También facilita la prueba de versiones nuevas con los datos existentes.

Versión predeterminada

Cada modelo con al menos una versión tiene una versión predeterminada; esta se establece cuando creas la primera versión. Si solicitas predicciones especificando solo un nombre de modelo, Cloud ML Engine, usa la versión predeterminada para ese modelo.

Ten en cuenta que la única vez en que el servicio configura automáticamente la versión predeterminada es cuando se crea la primera. Puedes configurar manualmente cualquier versión posterior como predeterminada llamando a projects.models.versions.setDefault (también expuesto como gcloud ml-engine versions set-default y como opción en la lista de versiones de la página de detalles del modelo en Google Cloud Platform Console [accede a la página de detalles del modelo haciendo clic en tu modelo en la lista de modelos de la página Modelos]). Esto te permite, por ejemplo, usar una versión predeterminada estable para entregar predicciones en producción y realizar pruebas de versiones más nuevas sin crear un recurso de modelo dedicado para las pruebas.

Asignación de nombres de modelos y versiones

Los nombres de los modelos y las versiones deben cumplir con las siguientes pautas:

  • Contener solamente combinaciones de mayúsculas y minúsculas, números y guiones bajos.
  • Comenzar con una letra.
  • Contener 128 caracteres o menos.
  • Ser únicos dentro de un proyecto dado (en el caso de los modelos) o de un modelo (en el caso de las versiones).

No existen reglas para los nombres además de esos requisitos técnicos, pero aquí tienes algunas prácticas recomendadas:

  • Los nombres de los modelos deben ser descriptivos y distintivos; es posible que debas identificarlos en una lista de muchos nombres en registros o informes.
  • Los nombres de versión cortos y simples son mejores. Es más fácil identificar “v1” que “2017_01_29T13_54_58”, por ejemplo, en una lista de recursos.

Límites de modelos y versiones

La política de cuotas de Cloud ML Engine establece un límite de 100 modelos por proyecto y limita la cantidad total de versiones (combinadas entre todos los modelos) a 200.

Parámetros de implementación del modelo

Cloud ML Engine necesita cierta información para crear tu versión del modelo. También hay algunas opciones que puedes configurar. En esta sección, se describen los parámetros de ambos tipos. Estos parámetros se definen en el objeto Version o se agregan por conveniencia en el comando gcloud ml-engine versions create.

Nombre de la versión
Un nombre de la versión nueva único entre los nombres de otras versiones del modelo.
Descripción
Puedes proporcionar una descripción de tu versión. Actualmente, solo se proporciona la descripción cuando recibes información de la versión con la API; ni la herramienta de línea de comandos de gcloud ni GCP Console muestran la descripción.
URI de implementación
Debes proporcionar el URI de la ubicación de Cloud Storage en la que está almacenado tu modelo guardado. Cloud ML Engine toma el modelo de esta ubicación y lo implementa. Este parámetro se denomina --origin en el comando gcloud ml-engine versions create.
Versión del entorno de ejecución
Cloud ML Engine usa la versión del entorno de ejecución estable más reciente para implementar tu versión del modelo, a menos que especifiques otra versión compatible. La versión del entorno de ejecución determina principalmente la versión de TensorFlow que usa el servicio de predicción para ejecutar tu modelo. Cuando ejecutas un trabajo de predicción por lotes, tienes la opción de anular la versión del entorno de ejecución asignada. La predicción en línea siempre usa la versión del entorno de ejecución configurada cuando se implementa la versión del modelo.
Ajuste de escala manual

Puedes especificar la cantidad de nodos de entrenamiento que deben seguir ejecutándose en tu versión del modelo. Consulta la sección sobre escalamiento para obtener más información.

Depósito de etapa de pruebas

Si usas la herramienta de línea de comandos de gcloud para implementar tu modelo, puedes usar un modelo guardado en tu computadora local. La herramienta lleva a cabo la etapa de pruebas en la ubicación de Cloud Storage que especificas antes de implementarlo en Cloud ML Engine.

Cambios de grafo para predicción

Es posible que hayas incluido operaciones de TensorFlow en tu grafo de procesamiento que fueron útiles principalmente en el contexto de entrenamiento. Una vez que hayas entrenado tu modelo, puedes quitar estas operaciones de los grafos antes de exportar la versión final.

Muchos de los consejos de la página de desarrollo de aplicaciones de entrenamiento están dirigidos a la experiencia de predicción. En algunos casos, son cambios que haces en el modelo una vez completada la mayor parte del entrenamiento y cuando estás listo para comenzar a implementar versiones.

Obtén predicciones

Puedes enviar datos nuevos a tus versiones de modelo implementadas para obtener predicciones. En las secciones a continuación, se describen consideraciones de predicción importantes.

Predicción en línea en comparación con predicción por lotes

Obtén más información sobre las diferencias entre las predicciones en línea y por lotes.

Comprende los nodos de predicción y la asignación de recursos

Cloud ML Engine mide la cantidad de procesamiento que consumes para la predicción en horas por nodo. En esta sección, se describen estos nodos y la forma en que se asignan para los distintos tipos de predicción.

Lo más sencillo es pensar en un nodo como una máquina virtual (VM), a pesar de que se implementan mediante un mecanismo diferente al de las VM tradicionales. Cada nodo está aprovisionado con una cantidad determinada de memoria y potencia de procesamiento. También posee una imagen del sistema operativo y una configuración determinada de software necesarias para ejecutar tu modelo y obtener predicciones.

Tanto la predicción en línea como por lotes ejecutan el nodo con procesamiento distribuido, por lo que una solicitud o un trabajo dados pueden usar varios nodos en simultáneo. Se te cobra el uso de nodos total por minuto, con una tarifa por hora. Por ejemplo, ejecutar dos nodos durante diez minutos se cobra lo mismo que ejecutar un nodo durante veinte minutos. Las predicciones en línea y por lotes asignan los nodos de distinta manera. Esto puede tener un efecto significativo en lo que se te cobrará.

Asignación de nodos en la predicción por lotes

El servicio de predicción por lotes ajusta la cantidad de nodos que utiliza, a fin de minimizar la cantidad de tiempo transcurrido que toma el trabajo. Para hacerlo, el servicio sigue estos pasos:

  • Asigna algunos nodos para administrar el trabajo cuando lo inicias.

  • Ajusta la cantidad de nodos durante el trabajo para intentar optimizar la eficiencia. Cada nodo demora en iniciarse, por lo que el servicio intenta asignar la cantidad justa para contrarrestar el tiempo de inicio con la reducción del tiempo transcurrido.

  • Cierra los nodos en cuanto se completa el trabajo.

Puedes modificar el escalamiento de un trabajo de predicción por lotes especificando una cantidad máxima de nodos para usar. Por lo general, querrás todos los nodos que el servicio usará, pero el uso de nodos está sujeto a la política de cuotas de Cloud ML Engine. Quizás quieras limitar la cantidad de nodos asignados a un trabajo dado, en especial si compartes tu proyecto con otros y potencialmente ejecutan trabajos (tanto de entrenamiento como de predicción) en forma simultánea.

Asignación de nodos en la predicción en línea

El servicio de predicción en línea ajusta la cantidad de nodos que utiliza a fin de maximizar la cantidad de solicitudes que puede administrar sin generar demasiada latencia. Para hacerlo, el servicio sigue estos pasos:

  • Asigna algunos nodos la primera vez que solicitas predicciones luego de una pausa prolongada en las solicitudes.

  • Ajusta la cantidad de nodos en respuesta al tráfico de solicitudes, agregando nodos cuando aumenta el tráfico y quitándolos cuando hay menos solicitudes.

  • Mantiene al menos un nodo listo durante varios minutos a fin de administrar solicitudes incluso cuando no hay ninguna presente. Este estado listo garantiza que el servicio pueda entregar cada predicción de manera oportuna.

  • Disminuye hasta cero cuando tu versión del modelo pasa varios minutos sin una solicitud de predicción.

Una vez que el servicio disminuyó hasta cero, o cuando hay un aumento repentino de tráfico, inicializar los nodos para entregar las solicitudes puede llevar tiempo (de segundos a minutos). El tiempo de inicialización depende del tamaño de la versión del modelo, por lo que el tiempo de espera del lado del cliente puede dar como resultado la pérdida de solicitudes hasta que los nodos nuevos se hayan inicializado o latencias mayores durante este período.

Para garantizar una entrega oportuna en todo momento, puedes especificar una cantidad mínima de nodos que el servicio debe tener listos configurando la opción minNodes en tu versión del modelo. Esta configuración puede aumentar el costo, dado que pagas por los nodos incluso si no se entregan predicciones.

Limitaciones del ajuste de escala automático

El ajuste de escala automático de Cloud ML Engine para la predicción en línea puede ayudarte a entregar velocidades variables de solicitudes de predicción y minimizar costos. Sin embargo, no es ideal en todas las situaciones. Es posible que el servicio no pueda conectar los nodos lo suficientemente rápido para seguir el ritmo de los grandes aumentos de tráfico de solicitudes. Si por lo general tu tráfico tiene aumentos pronunciados, y una latencia fehacientemente baja es importante para tu aplicación, quizás quieras considerar el ajuste de escala manual.

Usa el ajuste de escala manual

Puedes modificar el escalamiento de la predicción en línea de una versión del modelo especificando una cantidad de nodos que deben seguir ejecutándose independientemente del tráfico. Configurar la cantidad de nodos manualmente en realidad evita que el servicio realice un escalamiento, lo que significa que la cantidad de nodos que especificas siempre estarán listos y que se te cobrará por ellos de forma continua. Debes evitar esto, a menos que la cantidad de solicitudes que reciba tu modelo fluctúe, por su naturaleza, más rápido que la frecuencia de actualización del ajuste de escala automático. Puedes establecer la cantidad de nodos para usar configurando manualScaling en el objeto Version que pasas a projects.models.versions.create.

Datos de entrada de predicción

Los datos que usas para obtener predicciones son datos nuevos que toman la misma forma que los datos que usaste en el entrenamiento. Tanto la predicción en línea como por lotes usan los mismos datos (los atributos de tu modelo), pero requieren formatos diferentes según el tipo de predicción y la interfaz que uses. Estos formatos se resumen en la tabla a continuación y se describen en más detalle en las secciones siguientes:

Tipo de predicción; interfaz Formato de entrada compatible
Por lotes con llamada a la API Archivo de texto con strings de instancia JSON o archivo TFRecord (puede estar comprimido)
Por lotes con la herramienta de gcloud Archivo de texto con strings de instancia JSON o archivo TFRecord (puede estar comprimido)
En línea con llamada a la API Mensaje de solicitud JSON
En línea con la herramienta de gcloud Archivo de texto con strings de instancia JSON o archivo CSV

Strings de instancias JSON

El formato básico de las predicciones en línea y por lotes es una lista de tensores de datos de instancia. Pueden ser listas sin formato de valores o miembros de un objeto JSON, según cómo configuraste las entradas en la aplicación de entrenamiento.

En este ejemplo, se muestra un tensor de entrada y una clave de instancia:

{"values": [1, 2, 3, 4], "key": 1}

La composición de la string JSON puede ser compleja, siempre y cuando siga estas reglas:

  • El nivel superior de los datos de instancia debe ser un objeto JSON, un diccionario de pares de claves/valores.

  • Los valores individuales en un objeto de instancia pueden ser strings, números o listas. No puedes incorporar objetos JSON.

  • Las listas deben contener solo elementos del mismo tipo (incluidas otras listas). No puedes mezclar valores numéricos y strings.

La string siguiente (con formato para facilitar la lectura) muestra un objeto que contiene una etiqueta y una imagen, en el que la imagen es un arreglo tridimensional de enteros de 8 bits:

{
  "tag": "beach",
  "image": [
    [
      [138, 30, 66],
      [130, 20, 56],
      ...
    ],
    [
      [126, 38, 61],
      [122, 24, 57],
      ...
    ],
        ...
  ]
}

Si tu modelo solo toma una entrada, no necesitas unirla en un objeto JSON. Por ejemplo, si envías un solo tensor (vector en este caso) con cuatro valores, no necesitas darle el formato siguiente:

{"values": [1, 2, 3, 4]}

Simplemente puedes darle a cada instancia el formato de lista:

[1, 2, 3, 4]
Datos binarios en la entrada de predicción

No es posible darles a los datos binarios el formato de strings codificadas en UTF-8 que admite JSON. Si tienes datos binarios en tus entradas, debes usar la codificación base64 para representarlos. Se requiere el formato especial siguiente:

  • Tu string codificada debe tener el formato de un objeto JSON con una clave única llamada b64. El ejemplo de Python siguiente codifica un búfer de datos JPEG sin procesar usando la biblioteca base64 para crear una instancia:

    {"image_bytes":{"b64": base64.b64encode(jpeg_data)}}
    
  • En tu código de modelo TensorFlow, debes asignar los alias de los tensores de entrada y salida de modo que finalicen con “_bytes”.

Datos de entrada de predicción en línea

Pasas las instancias de entrada para la predicción en línea como el cuerpo del mensaje de la solicitud de predicción. Si deseas dar formato al cuerpo de la solicitud y la respuesta, consulta los detalles de la solicitud de predicción.

En resumen, haz que cada instancia sea un elemento en una lista y nombra instances al miembro de la lista. Entonces, el ejemplo JSON de instancia de datos simple anterior se convierte en lo siguiente:

{"instances": [{"values": [1, 2, 3, 4], "key": 1}]}

Cuando usas gcloud ml-engine projects predict para solicitar predicciones en línea, pasas un archivo con el mismo formato que usas en la predicción por lotes.

Datos de entrada de predicción por lotes

Proporcionas los datos de entrada para la predicción por lotes en uno o más archivos de texto que contienen filas de datos de instancia JSON como se describió anteriormente. Un archivo de entrada no contiene encabezados de columnas ni otro formato más allá de la sintaxis JSON simple.

{"image": [0.0, 0.0, ... ], "key": 0}
{"image": [0.0, 0.0, ... ], "key": 1}
{"image": [0.0, 0.0, ... ], "key": 2}

Claves de instancia

Cloud ML Engine ejecuta tus trabajos de predicción por lotes usando procesamiento distribuido. Esto significa que tus datos se distribuyen entre clústeres arbitrarios de máquinas virtuales y se procesan en un orden impredecible. Para poder correlacionar las predicciones mostradas con tus instancias de entrada, debes tener definidas claves de instancia. Una clave de instancia es un valor que tiene cada instancia y que es único entre todas las instancias de un conjunto de datos. La clave más simple es un número de índice.

Debes pasar las claves por tu grafo sin alterar en la aplicación de entrenamiento. Si tus datos todavía no tienen claves de instancia, puedes agregarlas como parte del procesamiento previo de los datos.

Versiones del entorno de ejecución

A medida que se lanzan versiones nuevas de Cloud ML Engine, es posible que los modelos desarrollados en versiones anteriores queden obsoletos. Esto resulta especialmente pertinente si logras una versión del modelo eficaz que no se modifica durante un período prolongado. Debes revisar la política de control de versiones de Cloud ML Engine y asegurarte de comprender la versión del entorno de ejecución de Cloud ML Engine que usas para entrenar tus versiones de modelos.

Versiones del entorno de ejecución y predicciones

Puedes especificar una versión compatible del entorno de ejecución de Cloud ML Engine cuando creas una versión del modelo. Al hacerlo, se establecerá la configuración predeterminada de la versión del modelo. Si no especificas una explícitamente, Cloud ML Engine crea tu versión usando la versión del entorno de ejecución 1.0 predeterminada actual.

Puedes especificar la versión del entorno de ejecución que se debe utilizar cuando inicias un trabajo de predicción por lotes. Esto permite la obtención de predicciones usando un modelo que no esté implementado en Cloud ML Engine. Para un modelo implementado, usa la versión del entorno de ejecución predeterminada del modelo en tu solicitud de trabajo. Si usas una versión diferente, es posible que se generen errores inesperados.

No puedes solicitar predicciones en línea a modelos fuera de Cloud ML Engine, por lo que no hay opción para anular la versión del entorno de ejecución predeterminada en tu solicitud.

No es posible modificar la versión del entorno de ejecución predeterminada configurada para una versión del modelo. Para especificar una versión del entorno de ejecución diferente en una versión del modelo, implementa una versión nueva usando los mismos artefactos de entrenamiento que usaste inicialmente.

Regiones y predicciones

Google Cloud Platform usa regiones, subdivididas en zonas, para definir la ubicación geográfica de los recursos de procesamiento físicos. Cuando implementas un modelo para la predicción usando Cloud ML Engine, especificas la región predeterminada en la que deseas que se ejecute la predicción.

Cuando comienzas un trabajo de predicción por lotes, puedes especificar una región en la que ejecutar el trabajo, lo cual anula la región predeterminada. Las predicciones en línea siempre se entregan desde la región predeterminada especificada para el modelo.

Para ver las regiones disponibles de los servicios de Cloud ML Engine, incluido el entrenamiento de modelos y la predicción en línea o por lotes, lee la guía de regiones.

Registro de predicciones

La predicción por lotes genera registros de trabajo que puedes ver en Stackdriver Logging. También puedes obtener registros de solicitudes de predicción en línea si configuras tu modelo, cuando lo creas, para generarlos. Ten en cuenta que debes especificar esta opción cuando creas el recurso de modelo en Cloud ML Engine; todas o ninguna de las versiones de un modelo generarán registros para las predicciones en línea.

Puedes configurar el registro de predicciones en línea de un modelo configurando onlinePredictionLogging como verdadero (True en Python) en el Recurso de modelo que usas cuando creas tu modelo con projects.models.create. Si usas la herramienta de línea de comandos de gcloud para crear tu modelo, incluye el marcador --enable-logging cuando ejecutes gcloud ml-engine models create.

Obtén predicciones a partir de modelos sin implementar

Puedes solicitar la predicción por lotes usando un modelo que no hayas implementado en el servicio de Cloud ML Engine. En lugar de especificar un nombre de modelo o versión, puedes usar el URI de una ubicación de Google Cloud Storage en la que esté almacenado el modelo que deseas ejecutar.

Debido a que un modelo sin implementar no posee una versión del entorno de ejecución predeterminada establecida, debes configurarla explícitamente en tu solicitud de trabajo. De lo contrario, Cloud ML Engine usará la versión del entorno de ejecución estable más reciente.

En todos los demás aspectos, un trabajo de predicción por lotes que usa un modelo no implementado se comporta como cualquier otro trabajo por lotes.

Pruebas de modelos

Puedes usar el servicio de predicción de Cloud ML Engine para alojar tus modelos en producción, pero también puedes usarlo a fin de realizar pruebas en los modelos. Tradicionalmente, las pruebas de modelos son un paso previo a la preparación para la implementación de una solución de aprendizaje automático. La finalidad de superar una prueba es evaluar el modelo en un entorno que se asemeje lo más posible a la forma en que se usará en situaciones reales.

Recuerda que puedes tener varias versiones de un modelo implementadas en simultáneo en el servicio. Esto significa que puedes tener varias revisiones de tu modelo a prueba al mismo tiempo, de ser necesario. También facilita el proceso tener implementada una versión de producción del modelo mientras pruebas la revisión siguiente. Al igual que con muchas aplicaciones de aprendizaje automático en desarrollo, la disponibilidad de datos recientes suele ser un factor limitante. Debes desarrollar estrategias para dividir los datos que posees y recopilar datos nuevos a fin de usarlos en las pruebas.

¿Qué sigue?

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Cloud ML Engine para TensorFlow