Reglas de aprendizaje automático:

Recomendaciones para la ingeniería de AA

Martín Zinkevich

El objetivo de este documento es ayudar a aquellas personas con conocimientos básicos sobre el aprendizaje automático a obtener el beneficio de las prácticas recomendadas de Google en cuanto al aprendizaje automático. Presenta un estilo, similar a la guía de estilo de Google para C++ y otras guías populares para la programación práctica. Si tomaste una clase sobre aprendizaje automático, o si compilaste o trabajaste en un modelo de aprendizaje automático, tienes los antecedentes necesarios para leer este documento.

Martin Zinkevich presenta 10 de sus reglas favoritas del aprendizaje automático. Sigue leyendo para conocer sus 43 reglas.

Terminología

Los siguientes términos se mencionarán con frecuencia en nuestra conversación sobre el aprendizaje automático eficaz:

  • Instancia: El aspecto sobre el que deseas hacer una predicción. Por ejemplo, la instancia puede ser una página web que deseas clasificar como "sobre gatos" o "no sobre gatos".
  • Etiqueta: Una respuesta a la tarea de predicción, que se puede generar mediante un sistema de aprendizaje automático o a partir de los datos de entrenamiento. Por ejemplo, la etiqueta para una página web puede ser "sobre gatos".
  • Atributo: Una propiedad de una instancia utilizada en una tarea de predicción. Por ejemplo, una página web puede tener un atributo "contiene la palabra 'gato'".
  • Columna de atributos: Un conjunto de atributos relacionados, como el conjunto de todos los países posibles donde es probable que vivan los usuarios. Un ejemplo puede tener uno o más atributos presentes en una columna de atributos. "Columna de atributos" es una terminología específica de Google. Una columna de atributos se conoce como un "espacio de nombres" en el sistema de VW (en Yahoo/Microsoft) o como un campo.
  • Ejemplo: Una instancia (con sus atributos) y una etiqueta.
  • Modelo: Una representación estadística de una tarea de predicción. Entrenas un modelo basado en ejemplos y, luego, lo usas para hacer predicciones.
  • Métrica: El número que importa. Pueden optimizarse directamente o no.
  • Objetivo: Una métrica que tu algoritmo intenta optimizar.
  • Canalización: La infraestructura que rodea al algoritmo de aprendizaje automático. Incluye la recopilación de datos del frontend, su incorporación a los archivos de datos de entrenamiento, el entrenamiento de uno o más modelos y la exportación de los modelos para la producción.
  • Tasa de clics: El porcentaje de visitantes a una página web que hacen clic en el vínculo de un anuncio.

Descripción general

Para fabricar excelentes productos:

aprende sobre el aprendizaje automático como el gran ingeniero que eres, no como el gran experto en aprendizaje automático que no eres.

De hecho, la mayoría de los problemas que debes afrontar son problemas de ingeniería. Incluso con todos los recursos de un gran experto en aprendizaje automático, la mayoría de los beneficios provienen de los atributos geniales, no de los algoritmos de aprendizaje automático excelentes. Por lo tanto, el enfoque básico es el siguiente:

  1. Asegúrate de que la canalización sea sólida de extremo a extremo.
  2. Comience con un objetivo razonable.
  3. Agrega funciones de sentido común de una manera sencilla.
  4. Asegúrate de que tu canalización se mantenga sólida.

Este enfoque funcionará bien por un período prolongado. Abandona este enfoque solo cuando no hay más trucos simples que te permitan avanzar. Agregar complejidad dificulta los próximos lanzamientos.

Una vez que hayas agotado los trucos simples, el aprendizaje automático de vanguardia podría ser en el futuro. Consulta la sección en los proyectos de aprendizaje automático de la Fase III.

Este documento se organiza de la siguiente manera:

  1. La primera parte te permite determinar si es el momento indicado para desarrollar un sistema de aprendizaje automático.
  2. La segunda parte se trata de implementar la primera canalización.
  3. La tercera parte cubre el lanzamiento y la iteración mientras se agregan atributos nuevos a la canalización, la evaluación de los modelos y la desviación entre el entrenamiento y la entrega.
  4. La parte final trata sobre qué hacer cuando alcanzas una meseta.
  5. Luego, hay una lista del trabajo relacionado y un apéndice con información sobre los sistemas que se usan comúnmente como ejemplos en este documento.

Antes del aprendizaje automático

Regla n.o 1: No tengas miedo de lanzar un producto sin aprendizaje automático.

El aprendizaje automático es genial, pero requiere datos. En teoría, puedes tomar datos de un problema diferente y, luego, ajustar el modelo para un producto nuevo, pero es probable que la capacidad de rendimiento sea inferior a la heurística básica. Si crees que el aprendizaje automático te dará un impulso del 100%, entonces una heurística te permitirá alcanzar el 50% del camino.

Por ejemplo, si clasificas apps en un mercado de apps, puedes usar la tasa de instalación o la cantidad de instalaciones como heurística. Si detectas spam, filtra los publicadores que ya enviaron spam. Tampoco tengas miedo de usar la edición humana. Si necesitas clasificar contactos, clasifica el que se usó más recientemente como el más alto (o incluso en orden alfabético). Si el aprendizaje automático no es absolutamente obligatorio para tu producto, no lo uses hasta que tengas datos.

Regla n.o 2: Primero, diseña e implementa métricas.

Antes de formalizar lo que hará el sistema de aprendizaje automático, realiza un seguimiento del sistema actual tanto como sea posible. Hazlo por los siguientes motivos:

  1. Es más fácil obtener permiso de los usuarios del sistema al principio.
  2. Si crees que algo puede preocupar en el futuro, es mejor obtener datos históricos ahora.
  3. Si diseñas el sistema con la instrumentación de métricas en mente, las cosas irán mejorando en el futuro, En especial, si no deseas realizar búsquedas globales de strings en registros para instrumentar las métricas.
  4. Notará lo que cambia y lo que no cambia. Por ejemplo, supongamos que deseas optimizar directamente a los usuarios activos por un día. Sin embargo, durante las primeras manipulaciones del sistema, es posible que notes que los cambios drásticos en la experiencia del usuario no cambian esta métrica de forma notoria.

El equipo de Google+ mide las expansiones por lectura, los elementos compartidos por lectura, los +1 por lectura, los comentarios por lectura, los comentarios por usuario, la cantidad de veces que se compartió el usuario, etc., que utilizan para calcular el valor de una publicación durante la publicación. Además, ten en cuenta que es importante un marco de trabajo experimental, en el que puedes agrupar usuarios y agrupar estadísticas por experimento. Consulta la regla n.o 12.

Si recopilas métricas de forma más liberal, puedes obtener una visión más amplia de tu sistema. ¿Notas algún problema? Agregue una métrica para realizar su seguimiento ¿Te entusiasma algún cambio cuantitativo en la última versión? Agregue una métrica para realizar su seguimiento

Regla n.o 3: Elige el aprendizaje automático en lugar de una heurística compleja.

Una heurística simple puede sacar su producto de la puerta. Una heurística compleja no es sostenible. Una vez que tengas los datos y una idea básica de lo que intentas lograr, pasa al aprendizaje automático. Al igual que en la mayoría de las tareas de ingeniería de software, deberás actualizar tu enfoque de manera constante, ya sea con un modelo heurístico o de aprendizaje automático. Notarás que el modelo de aprendizaje automático es más fácil de actualizar y mantener (consulta la regla n.o 16).

Fase I de AA: tu primera canalización

Concéntrate en la infraestructura de tu sistema para tu primera canalización. Si bien es divertido pensar en todo el aprendizaje automático imaginativo que realizarás, será difícil determinar qué sucede si no confías en tu canalización.

Regla n.o 4: Mantén el primer modelo simple y haz la infraestructura correcta.

El primer modelo proporciona el mayor impulso para tu producto, por lo que no necesita ser muy sofisticado. Sin embargo, te encontrarás con muchos más problemas de infraestructura de los que esperas. Antes de que alguien pueda usar tu novedoso sistema de aprendizaje automático, debes determinar lo siguiente:

  • Cómo obtener ejemplos para tu algoritmo de aprendizaje.
  • Un primer corte en cuanto a lo que significa "bueno" y "malo" para tu sistema.
  • Cómo integrar el modelo a tu aplicación Puedes aplicar el modelo en vivo o realizar un procesamiento previo del modelo en ejemplos sin conexión y almacenar los resultados en una tabla. Por ejemplo, es posible que desees clasificar con anterioridad las páginas web y almacenar los resultados en una tabla, pero deberías clasificar los mensajes de chat en vivo.

Elegir funciones simples facilita asegurar lo siguiente:

  • Las funciones llegan a su algoritmo de aprendizaje correctamente.
  • El modelo aprende ponderaciones razonables.
  • Los atributos llegan correctamente a tu modelo en el servidor.

Una vez que tienes un sistema que hace estas tres tareas de manera confiable, hiciste la mayor parte del trabajo. Tu modelo simple te proporciona métricas de referencia y un comportamiento de referencia que puedes usar para probar modelos más complejos. Algunos equipos apuntan a un primer lanzamiento "neutral": un primer lanzamiento que da prioridad de manera explícita a las ganancias del aprendizaje automático para evitar la distracción.

Regla n.o 5: Prueba la infraestructura independientemente del aprendizaje automático.

Asegúrate de que la infraestructura se pueda probar y de que las partes de aprendizaje del sistema estén encapsuladas para que puedas probar todo lo que la rodea. En particular, haz lo siguiente:

  1. Pruebe ingresar datos al algoritmo. Comprueba que se completen las columnas de atributos que deben completarse. Cuando la privacidad lo permita, inspecciona de forma manual las entradas del algoritmo de entrenamiento. Si es posible, comprueba las estadísticas en tu canalización para compararlas con las estadísticas de los mismos datos procesados en otro lugar.
  2. Prueba obtener modelos a partir del algoritmo de entrenamiento. Asegúrate de que el modelo de tu entorno de entrenamiento muestre la misma puntuación que el modelo del entorno de entrega (consulta la regla n.o 37).

El aprendizaje automático tiene un elemento de incertidumbre, por lo que debes asegurarte de tener pruebas para el código a fin de crear ejemplos en el entrenamiento y la entrega. También, puedes cargar y usar un modelo fijo durante la entrega. Además, es importante comprender los datos: consulta Consejos prácticos para el análisis de conjuntos de datos grandes y complejos.

Regla n.o 6: Ten cuidado con la pérdida de datos cuando se copian las canalizaciones.

A menudo, creamos una canalización mediante la copia de una existente (es decir, la programación a ciegas), y la canalización anterior descarta datos que necesitamos para la canalización nueva. Por ejemplo, la canalización para la vista Lo más interesante de Google+ pierde las publicaciones anteriores (porque intenta calificar las publicaciones nuevas). Esta canalización se copió para usarla en las Novedades de Google+, donde las publicaciones anteriores todavía tienen valor. Sin embargo, la canalización sigue perdiendo publicaciones antiguas. Otro patrón común es solo registrar datos que vio el usuario. Por lo tanto, estos datos no son útiles si queremos modelar el motivo por el que el usuario no vio una publicación en particular, porque todos los ejemplos negativos se descartaron. Ocurrió un problema similar en Play. Durante el trabajo en la página principal de apps de Play, se creó una canalización nueva que también contenía ejemplos de la página de destino de Play Juegos sin ninguna función para desambiguar cada origen.

Regla n.o 7: Convierte la heurística en elementos o gestiónalos de forma externa.

Por lo general, los problemas que el aprendizaje automático intenta resolver no son del todo nuevos. Ya existe un sistema para la clasificación, la clasificación o cualquier problema que intentes resolver. Esto significa que existen muchas reglas y heurísticas. La misma heurística puede ayudarte a mejorar cuando se ajusta con el aprendizaje automático. Tu heurística debe ser extraída por cualquier información que tenga, por dos razones. Primero, la transición a un sistema de aprendizaje automático será más fluida. En segundo lugar, por lo general, esas reglas contienen mucha intuición sobre el sistema que no deseas descartar. Existen cuatro maneras de usar una heurística existente:

  • Procesar previamente con la heurística Si el atributo es increíblemente asombroso, entonces esta es una opción. Por ejemplo, si, en un filtro de spam, el remitente ya está en la lista negra, no intentes volver a aprender qué significa "estar en la lista negra". Bloquea el mensaje. Este enfoque tiene más sentido en tareas de clasificación binaria.
  • Crea un elemento. Crear un atributo directamente a partir de la heurística es genial. Por ejemplo, si usas una heurística para calcular una puntuación de relevancia para el resultado de una consulta, puedes incluir la puntuación como el valor de un atributo. Más adelante, es posible que desees usar técnicas de aprendizaje automático para adaptar el valor (por ejemplo, al convertir el valor en uno de un conjunto finito de valores discretos o al combinarlo con otros atributos), pero comienza usando los valores sin procesar que produce la heurística.
  • Recolecta las entradas sin procesar de la heurística. Si existe una heurística para apps que combine la cantidad de instalaciones, la cantidad de caracteres en el texto y el día de la semana, considera separar estos datos y enviar estas entradas al aprendizaje por separado. En este caso, puedes usar algunas técnicas que usan los conjuntos (consulta la regla n.o 40).
  • Modifica la etiqueta. Esta es una opción cuando consideras que la heurística captura información que no está contenida actualmente en la etiqueta. Por ejemplo, si intentas maximizar la cantidad de descargas, pero también deseas obtener contenido de calidad, la solución puede ser multiplicar la etiqueta por la cantidad promedio de estrellas que recibió la app. Hay mucha libertad aquí. Consulta "Tu primer objetivo".

Ten en cuenta la complejidad agregada cuando uses heurísticas en un sistema de AA. Usar heurísticas antiguas en tu algoritmo de aprendizaje automático nuevo puede ayudarte a crear una transición sin problemas, pero piensa si existe una manera más simple de lograr el mismo efecto.

Supervisión

En general, ten en cuenta la higiene de las alertas, como crear alertas prácticas y tener una página de panel.

Regla n.o 8: Conoce los requisitos de actualidad de tu sistema.

¿Cuánto se degrada el rendimiento si tiene un modelo que tiene un día de antigüedad? ¿Y una semana? ¿Un cuarto de edad? Esta información puede ayudarte a comprender las prioridades de la supervisión. Si pierdes la calidad significativa del producto si el modelo no se actualiza por un día, tiene sentido que un ingeniero lo mire de forma continua. La mayoría de los sistemas de publicación de anuncios tienen anuncios nuevos que manejar cada día y deben actualizarse a diario. Por ejemplo, si el modelo de AA para Búsqueda de Google Play no está actualizado, puede tener un impacto negativo en menos de un mes. Algunos modelos de la sección Lo más interesante en Google+ no tienen un identificador de publicaciones, por lo que pueden exportar estos modelos de forma poco frecuente. Otros modelos que tienen identificadores de publicación se actualizan con mucha más frecuencia. Además, ten en cuenta que la actualidad puede cambiar con el tiempo, en especial cuando se agregan o quitan columnas de atributos en el modelo.

Regla n.o 9: Detecta los problemas antes de exportar los modelos.

Muchos sistemas de aprendizaje automático tienen una etapa en la que exportas el modelo para la entrega. Si hay un problema con un modelo exportado, es un problema para el usuario.

Realiza verificaciones de estado justo antes de exportar el modelo. Específicamente, asegúrate de que el rendimiento del modelo sea razonable para los datos retenidos. O, si tienes inquietudes persistentes con los datos, no exportes un modelo. Muchos equipos que implementan continuamente modelos comprueban el área bajo la curva ROC (o AUC) antes de la exportación. Para los problemas sobre modelos que no se exportaron, se requiere una alerta por correo electrónico, pero los problemas en un modelo orientado al usuario pueden requerir una página. Así que es mejor esperar y estar seguro antes de afectar a los usuarios.

Regla n.o 10: Busca los fallos silenciosos.

Este es un problema que ocurre más en los sistemas de aprendizaje automático que en otros tipos de sistemas. Supongamos que una tabla en particular que se une ya no se actualiza. El sistema de aprendizaje automático se ajustará y el comportamiento continuará siendo razonablemente bueno, con una degradación gradual. A veces, hay tablas con meses de atraso y una actualización simple mejora el rendimiento más que cualquier otro lanzamiento de ese trimestre. La cobertura de un atributo puede cambiar debido a los cambios en la implementación; por ejemplo, una columna de atributos podría propagarse en el 90% de los ejemplos y, de repente, disminuir al 60% de los ejemplos. Una vez, Play tuvo una tabla que estaba inactiva durante 6 meses, y actualizar solo la tabla aumentó la tasa de instalación en un 2%. Si realizas un seguimiento de las estadísticas de los datos y, además, inspeccionas de forma manual los datos en ocasiones, puedes reducir este tipo de fallas.

Regla n.o 11: Proporciona documentación y propietarios a las columnas de atributos.

Si el sistema es grande y hay muchas columnas de atributos, debes saber quién creó o mantiene cada columna de atributos. Si descubres que la persona que comprende una columna de atributos se va, asegúrate de que alguien tenga la información. Aunque muchas columnas de atributos tienen nombres descriptivos, es recomendable tener una descripción más detallada de qué es el atributo, de dónde proviene y cómo se espera que ayude.

Tu primer objetivo

Si bien te importan varias métricas o mediciones sobre el sistema, el algoritmo de aprendizaje automático a menudo requiere un objetivo único, un número que el algoritmo "intenta" optimizar. Distingo aquí entre objetivos y métricas: una métrica es cualquier número que informa el sistema, que puede o no ser importante. Consulta también la regla n.o 2.

Regla n.o 12: No pienses demasiado qué objetivo eliges optimizar directamente.

Quieres ganar dinero, satisfacer a los usuarios y hacer del mundo un lugar mejor. Hay cientos de métricas para tener en cuenta y debes medirlas a todas (consulta la regla n.o 2). Sin embargo, al comienzo del proceso de aprendizaje automático, notarás que todos aumentan, incluso aquellos que no optimizas directamente. Por ejemplo, supongamos que te interesan la cantidad de clics y el tiempo en el sitio. Si optimizas para obtener más clics, es probable que notes un aumento en el tiempo invertido.

Por lo tanto, debes ser simple y no pensar demasiado en el equilibrio entre las diferentes métricas cuando aún puedes aumentarlas fácilmente. Pero no lleves esta regla demasiado lejos: no confundas tu objetivo con el estado final del sistema (consulta la regla n.o 39). Además, si aumentas la métrica optimizada directamente, pero decides no iniciarla, es posible que debas revisar los objetivos.

Regla n.o 13: Elige una métrica simple, observable y con atributos para tu primer objetivo.

A menudo, no sabes cuál es el verdadero objetivo. Piensas que sí, pero cuando observas los datos y el análisis en paralelo de tu sistema anterior y el nuevo sistema de AA, te das cuenta de que debes modificar el objetivo. Además, los diferentes miembros de equipo a menudo no están de acuerdo con el verdadero objetivo. El objetivo de AA debe ser algo fácil de medir y una representación del objetivo "verdadero". De hecho, a menudo no existe un "verdadero" objetivo (consulta la regla n.o 39). Por lo tanto, entrena sobre el objetivo de AA simple y considera tener una "capa de políticas" en la parte superior que te permita agregar lógica adicional (con suerte, una lógica muy simple) para realizar la clasificación final.

Lo más fácil de modelar es un comportamiento de los usuarios que se observa directamente y se puede atribuir a una acción del sistema:

  • ¿Se hizo clic en este vínculo clasificado?
  • ¿Se descargó este objeto clasificado?
  • ¿Se reenvió o respondió este objeto clasificado o se le envió un correo electrónico?
  • ¿Se calificó este objeto clasificado?
  • ¿El objeto que se muestra se marcó como spam, pornografía u ofensivo?

Evita el modelado de efectos indirectos al principio:

  • ¿El usuario realizó una visita al día siguiente?
  • ¿Durante cuánto tiempo el usuario visitó el sitio?
  • ¿Cuáles fueron los usuarios activos por día?

Los efectos indirectos son métricas excelentes y se pueden usar durante las pruebas A/B y las decisiones de lanzamiento.

Por último, no intente utilizar el aprendizaje automático para determinar lo siguiente:

  • ¿El usuario está feliz con el producto?
  • ¿El usuario está satisfecho con la experiencia?
  • ¿El producto mejora el bienestar general del usuario?
  • ¿Cómo afectará esto al estado de salud general de la empresa?

Todo esto es importante, pero también increíblemente difícil de medir. En su lugar, usa proxies: si el usuario está satisfecho, permanecerá en el sitio por más tiempo. Si el usuario está satisfecho, volverá a visitarlo mañana. En cuanto al bienestar y el estado de la empresa, se requiere el criterio humano para conectar el objetivo del aprendizaje automático con la naturaleza del producto que vendes y tu plan empresarial.

Regla n.o 14: Comenzar con un modelo interpretable facilita la depuración.

La regresión lineal, la regresión logística y la regresión de Poisson están directamente relacionadas con un modelo probabilístico. Cada predicción se interpreta como una probabilidad o un valor esperado. Esto los hace más fáciles de depurar que los modelos que usan objetivos (pérdida cero, varias pérdidas de bisagra, etc.) que intentan optimizar directamente la precisión de la clasificación o el rendimiento de la clasificación. Por ejemplo, si las probabilidades en el entrenamiento se desvían de las probabilidades predichas en la comparación o la inspección del sistema de producción, esta desviación podría revelar un problema.

Por ejemplo, en la regresión lineal, logística o de Poisson, existen subconjuntos de datos donde la expectativa promedio de las predicciones equivale a la etiqueta promedio (calibrado con un momento o simplemente calibrado). Esto es verdadero en caso de que no tengas una regularización y de que tu algoritmo haya convergido, y es bastante verdadero en general. Si tienes un atributo que es 1 o 0 para cada ejemplo, entonces el conjunto de 3 ejemplos en el que ese atributo es 1 está calibrado. Además, si tienes un atributo que es 1 para cada ejemplo, el conjunto de todos los ejemplos se calibra.

Con modelos simples, es más fácil lidiar con ciclos de reacción (consulta la regla n.o 36). A menudo, usamos estas predicciones probabilísticas para tomar una decisión: p. ej., clasificar las publicaciones en el valor esperado decreciente (es decir, la probabilidad de hacer clic, descargar, etc.). Sin embargo, recuerda que cuando debes elegir qué modelo usar, la decisión importa más que la probabilidad de los datos según el modelo (consulta la regla n.o 27).

Regla n.o 15: Separa el filtro de spam y la clasificación de calidad en una capa de política.

La clasificación de calidad es un arte delicado, pero el filtro de spam es una guerra. Los indicadores que uses para determinar las publicaciones de alta calidad serán evidentes para los usuarios que usen tu sistema, y ajustarán sus publicaciones para tener estas propiedades. Por lo tanto, tu clasificación de calidad debe enfocarse en clasificar el contenido que se publica de buena fe. No debes descuidar el aprendizaje de clasificación de calidad por clasificar contenido en alto spam. De manera similar, el contenido subido de tono debe manejarse por separado de la clasificación de calidad. El filtro de spam es una historia diferente. Es esperable que los atributos que necesitas generar cambien constantemente. A menudo, habrá reglas obvias que pongas en el sistema (si una publicación tiene más de tres votos de spam, no la recuperes, etcétera). Cualquier modelo aprendido debe actualizarse a diario o de forma más rápida. La reputación del creador del contenido tendrá un papel muy importante.

En algún nivel, se deberá integrar el resultado de estos dos sistemas. Ten en cuenta que es probable que el filtrado de spam en los resultados de la búsqueda sea más agresivo que en los mensajes de correo electrónico. Esto es verdadero en caso de que no tengas regularización y de que tu algoritmo haya convergido. En general, es bastante cierto. Además, se recomienda quitar el spam de los datos de entrenamiento para el clasificador de calidad.

Fase II de aprendizaje automático: Ingeniería de atributos

En la primera fase del ciclo de vida de un sistema de aprendizaje automático, los problemas importantes son ingresar los datos de entrenamiento en el sistema de aprendizaje, obtener las métricas de interés instrumentadas y crear una infraestructura de entrega. Una vez que tienes un sistema integral de extremo a extremo con pruebas de unidades y sistemas instrumentadas, comienza la fase II.

En la segunda fase, hay muchas frutas bajas. Existe una variedad de atributos obvios que se pueden agregar al sistema. Por lo tanto, la segunda fase de aprendizaje automático implica extraer tantos atributos como sea posible y combinarlos de formas intuitivas. Durante esta fase, todas las métricas deberían seguir aumentando. Habrá muchos lanzamientos, y es un buen momento para incorporar muchos ingenieros que puedan unir todos los datos que necesitas para crear un sistema de aprendizaje realmente asombroso.

Regla n.o 16: Planifica el lanzamiento y la iteración.

No esperes que el modelo en el que trabajas ahora sea el último que lanzarás o, incluso, que alguna vez dejarás de lanzarlos. Por lo tanto, considera si la complejidad que estás agregando con este lanzamiento ralentizará los lanzamientos futuros. Muchos equipos han lanzado un modelo por trimestre o más durante años. Existen tres razones básicas para lanzar modelos nuevos:

  • Se te ocurren nuevas funciones.
  • Estás ajustando la regularización y combinando los atributos antiguos de nuevas maneras.
  • Estás ajustando el objetivo.

Sin embargo, darle un poco de amor a un modelo puede ser bueno: revisar los datos que se ingresan en el ejemplo puede ayudar a encontrar señales nuevas y antiguas. Por lo tanto, a medida que compilas tu modelo, piensa en lo fácil que es agregar, quitar o recombinar atributos. Piensa en lo fácil que es crear una copia nueva de la canalización y verificar que sea correcta. Piensa en si es posible ejecutar dos o tres copias en paralelo. Por último, no te preocupes por si la característica 16 de 35 aparece en esta versión de la canalización. Lo recibirás el próximo trimestre.

Regla n.o 17: Comienza con los atributos directamente observados e informados, en lugar de los atributos aprendidos.

Este puede ser un punto polémico, pero evita muchos errores. En primer lugar, describamos qué es un atributo aprendido. Un atributo aprendido es uno que genera un sistema externo (como un sistema de agrupamiento en clústeres no supervisado) o el mismo aprendizaje (p.ej., a través de un modelo factorizado o aprendizaje profundo). Ambos pueden ser útiles, pero pueden tener muchos problemas, por lo que no deberían estar en el primer modelo.

Si usas un sistema externo para crear un atributo, recuerda que el sistema externo tiene su propio objetivo. El objetivo del sistema externo solo puede estar poco relacionado con tu objetivo actual. Si tomas una instantánea del sistema externo, es posible que esté desactualizada. Si actualizas los atributos del sistema externo, los significados pueden cambiar. Si usas un sistema externo para proporcionar una función, ten en cuenta que este enfoque requiere mucha atención.

El problema principal con los modelos factorizados y profundos es que no son convexos. Por lo tanto, no hay garantía de que se pueda aproximar o encontrar una solución óptima, y el mínimo local que se encuentre en cada iteración puede ser diferente. Esta variación hace que sea difícil evaluar si el impacto de un cambio en el sistema es significativo o aleatorio. Si creas un modelo sin atributos profundos, obtienes un excelente rendimiento de referencia. Después de lograr este modelo de referencia, puedes probar enfoques más esotéricos.

Regla n.o 18: Explora con funciones de contenido que generalizan en distintos contextos.

A menudo, un sistema de aprendizaje automático es una parte pequeña de una imagen mucho más grande. Por ejemplo, si imaginas una entrada que podría usarse en Lo más interesante, muchas personas harán +1 en la publicación, la comentarán o la comentarán antes de que aparezca en Lo más interesante. Si proporcionas esas estadísticas al alumno, es posible que se promuevan las entradas nuevas para las que no tiene datos en el contexto que está optimizando. YouTube Watch Next puede usar la cantidad de veces que se miró un video, o que se miró un video de forma secuencial (la cantidad de veces que se miró un video después de otro) en la búsqueda de YouTube. También puedes usar calificaciones de usuarios explícitas. Por último, si tienes una acción del usuario que usas como etiqueta, ver esa acción en el contexto en un contexto diferente puede ser un excelente atributo. Todas estas funciones te permiten aportar contenido nuevo al contexto. Ten en cuenta que no se trata de personalización: primero, descubre si a alguien le gusta el contenido. Luego, descubre a quién le gusta más o menos.

Regla n.o 19: Usa funciones muy específicas cuando sea posible.

Con toneladas de datos, es más fácil aprender millones de atributos simples que unos pocos atributos complejos. Los identificadores de documentos que se recuperan y las consultas canónicas no brindan mucha generalización, pero alinean tu clasificación con las etiquetas en las consultas principales. Por lo tanto, no le temas a los grupos de atributos si cada uno se aplica a una fracción muy pequeña de tus datos, pero la cobertura general es superior al 90%. Puedes usar la regularización para eliminar los atributos que se aplican a muy pocos ejemplos.

Regla n.o 20: Combina y modifica los atributos existentes para crear nuevos atributos en lenguaje natural.

Existen varias formas de combinar y modificar atributos. Los sistemas de aprendizaje automático como TensorFlow te permiten preprocesar los datos mediante transformaciones. Los dos enfoques más estándares son las "discretizaciones" y las "combinaciones".

La discretización consiste en tomar un atributo continuo y crear muchos atributos discretos. Considera un atributo continuo como la edad. Puedes crear un atributo que es 1 cuando la edad es menor de 18, otro atributo que es 1 cuando la edad es entre 18 y 35, etc. No pienses demasiado en los límites de estos histogramas; los cuantiles básicos serán los más eficaces.

Las combinaciones combinan dos o más columnas de atributos. Una columna de atributos, en la terminología de TensorFlow, es un conjunto de atributos homogéneos (p. ej., {masculino, femenino}, {EE.UU., Canadá, México}, etc.). Una combinación es una nueva columna de atributos que incluye, p. ej., {masculino, femenino} × {EE.UU., Canadá, México}. Esta nueva columna de atributos contendrá el atributo (masculino, Canadá). Si usas TensorFlow y le indicas que cree esta combinación, este atributo (masculino, Canadá) estará presente en los ejemplos que representan a los hombres de Canadá. Ten en cuenta que se necesitan enormes cantidades de datos para aprender modelos con combinaciones de tres, cuatro o más columnas de atributos básicos.

Las combinaciones que producen columnas de atributos muy grandes pueden sobreajustar. Por ejemplo, imagina que haces algún tipo de búsqueda y tienes una columna de atributos con palabras en la consulta y una columna de atributos con palabras en el documento. Puedes combinarlos con una combinación, pero obtendrás muchos atributos (consulta la regla n.o 21).

Cuando se trabaja con texto, hay dos alternativas. Lo más drástico es un producto escalar. Un producto escalar en su forma más simple simplemente cuenta la cantidad de palabras en común entre la consulta y el documento. Esta característica se puede discretizar. Otro enfoque es una intersección: por lo tanto, tendremos un atributo que está presente solo si la palabra “poni” aparece en el documento y en la consulta, y otro atributo que está presente solo si la palabra “el” está en el documento y en la consulta.

Regla n.o 21: La cantidad de pesos de atributos que puedes aprender en un modelo lineal es casi proporcional a la cantidad de datos que tienes.

Existen resultados teóricos fascinantes sobre aprendizaje estadístico relacionados con el nivel de complejidad correspondiente de un modelo, pero esta regla es todo lo que necesitas saber. Tuve conversaciones en las que las personas tenían dudas sobre que se podía aprender algo de mil ejemplos, o que uno necesitaría más de un millón de ejemplos, porque están atascados en un determinado método de aprendizaje. La clave es escalar el aprendizaje al tamaño de los datos:

  1. Si estás trabajando en un sistema de clasificación de búsqueda, y hay millones de palabras diferentes en los documentos y en la consulta y tienes 1, 000 ejemplos etiquetados, debes usar un producto de punto entre los atributos de documento y consulta, TF-IDF y media docena de otras características de ingeniería humana. 1,000 ejemplos, una docena de atributos.
  2. Si tienes un millón de ejemplos, intersecta la columna de atributos de consultas con la de documentos, y aplica regularización y, posiblemente, selección de atributos. Esto te brindará un millón de atributos, pero, con la regularización, tendrás menos. Diez millones de ejemplos, quizás cien mil atributos.
  3. Si tienes miles o cientos de miles de millones, puedes combinar las columnas de atributos con tokens de consultas y de documentos mediante la regularización y la selección de atributos. Tendrás mil millones de ejemplos y 10 millones de atributos. La teoría de aprendizaje estadístico raramente establece límites rígidos, pero ofrece un buen punto de partida.

Por último, usa la regla n.o 28 para decidir qué funciones usar.

Regla n.o 22: Borra las funciones que ya no uses.

Los atributos sin usar crean deuda técnica. Si descubres que no estás usando una función y que combinarla con otras no funciona, quítala de la infraestructura. Debes mantener limpia tu infraestructura para que las funciones más prometedoras se puedan probar lo más rápido posible. Si es necesario, siempre se puede volver a agregar la función.

Ten en cuenta la cobertura cuando evalúes qué funciones agregarás o conservarás. ¿Cuántos ejemplos cubre el atributo? Por ejemplo, si tienes algunas funciones de personalización, pero solo el 8% de los usuarios tienen características de personalización, esto no será muy efectivo.

Al mismo tiempo, algunos atributos te sorprenden gratamente. Por ejemplo, si tienes un atributo que cubre solo el 1% de los datos, pero el 90% de los ejemplos del atributo son positivos, será un gran atributo para agregar.

Análisis humano del sistema

Antes de pasar a la tercera fase del aprendizaje automático, es importante enfocarse en algo que no se enseña en ninguna clase de aprendizaje automático: cómo analizar un modelo existente y mejorarlo. Esto es más un arte que una ciencia y, sin embargo, hay varios antipatrones que ayuda a evitar.

Regla n.o 23: No eres un usuario final típico.

Quizás esta es la manera más fácil de que un equipo se enganche. Si bien la pesca (con un prototipo dentro del equipo) y la prueba interna (con un prototipo dentro de la empresa) ofrecen muchos beneficios, los empleados deben analizar si el rendimiento es correcto. Si bien no se debe usar un cambio que obviamente sea malo, cualquier prueba que parezca razonablemente cercana a la producción se debe probar más a fondo, ya sea pagando a los usuarios básicos para que respondan preguntas en una plataforma de participación colectiva o mediante un experimento en vivo sobre usuarios reales.

Esto se debe a dos motivos. El primero es que estás muy cerca del código. Es posible que busques un aspecto específico de las publicaciones, o que estés muy involucrado (p.ej., sesgo de confirmación). El segundo es que su tiempo es demasiado valioso. Considera el costo de nueve ingenieros en una reunión de una hora y piensa cuántas etiquetas humanas contratadas compraron en una plataforma de participación colectiva.

Si realmente quieres comentarios de usuarios, usa las metodologías de experiencia del usuario. Crea usuarios persona (puedes encontrar una descripción en el libro Sketching User Experiences [Cómo diseñar experiencias de usuario] de Bill Buxton) al comienzo del proceso, y haz pruebas de usabilidad más adelante (puedes encontrar una descripción en Don’t Make Me Think (No me hagas pensar) de Steve Krug). Los usuarios persona implican crear un usuario hipotético. Por ejemplo, si tu equipo se compone solo por hombres, puede ser útil diseñar una persona femenina de 35 años (completa con las características del usuario) y observar los resultados que genera en lugar de los 10 para hombres de 25 a 40 años. Lograr que personas reales miren su reacción en tu sitio (de forma local o remota) durante las pruebas de usabilidad también puede darte una nueva perspectiva.

Regla n.o 24: Mide el delta entre los modelos.

Una de las mediciones más útiles y, a veces, más útiles que puedes hacer antes de que cualquier usuario mire tu modelo nuevo es calcular qué tan diferentes son los resultados nuevos de la producción. Por ejemplo, si tienes un problema de clasificación, ejecuta ambos modelos en una muestra de consultas en todo el sistema y observa el tamaño de la diferencia simétrica de los resultados (ponderados por la posición de la clasificación). Si la diferencia es muy pequeña, entonces puedes saber sin realizar un experimento que habrá pocos cambios. Si la diferencia es muy grande, entonces debes asegurarte de que el cambio sea bueno. Analizar las consultas en las que la diferencia simétrica es alta puede ayudarte a comprender de forma cualitativa cómo fue el cambio. Sin embargo, asegúrate de que el sistema sea estable. Cuando se compara un modelo consigo mismo, asegúrate de que tenga una diferencia simétrica baja (idealmente cero).

Regla n.o 25: Cuando eliges modelos, el rendimiento funcional tiene prioridad sobre el poder predictivo.

Es posible que el modelo intente predecir la tasa de clics. Sin embargo, en última instancia, la pregunta clave es lo que haces con esa predicción. Si la usas para clasificar documentos, la calidad de la clasificación final es más importante que la predicción en sí misma. Si predices la probabilidad de que un documento sea spam y, luego, tienes un límite en el contenido bloqueado, la precisión de lo que se permite tiene más importancia. La mayoría de las veces, estos dos aspectos coinciden. Cuando no estás de acuerdo, es probable que haya una pequeña ganancia. Por lo tanto, si hay algún cambio que mejora la pérdida logística, pero degrada el rendimiento del sistema, busca otra característica. Cuando esto comienza a suceder con más frecuencia, es hora de volver a revisar el objetivo del modelo.

Regla n.o 26: Busca patrones en los errores medidos y crea nuevas funciones.

Supongamos que ves un ejemplo de entrenamiento que el modelo está “incorrecto”. En una tarea de clasificación, este error puede ser un falso positivo o un falso negativo. En una tarea de clasificación, el error puede ser un par donde un positivo tiene una clasificación inferior a una negativa. El punto más importante es que este sea un ejemplo que el sistema de aprendizaje automático sepa que no lo entendió y que lo corrija si tiene la oportunidad. Si le das al atributo una característica que le permita corregir el error, el modelo intentará usarlo.

Por otro lado, si intentas crear un atributo basado en ejemplos que el sistema no considera errores, este se ignorará. Por ejemplo, supongamos que, en la búsqueda de apps de Play, alguien busca "juegos gratuitos". Imagina que uno de los resultados principales es una app de bromas menos relevante, es decir, creas una función para "apps de bromas". Sin embargo, si maximizas la cantidad de instalaciones y las personas instalan una app de bromas cuando buscan juegos gratuitos, la función de "apps de bromas" no tendrá el efecto que deseas.

Una vez que tengas ejemplos de los errores del modelo, busca tendencias que estén fuera del conjunto de atributos actual. Por ejemplo, si el sistema parece descender de nivel las publicaciones más largas, agrega la longitud de la publicación. No seas demasiado específico sobre las características que agregues. Si agregas la longitud de la publicación, no intentes adivinar qué significa "largo", solo agrega una decena de atributos y permite que el modelo descubra qué hacer con ellos (consulta la regla n.o 21). Esa es la manera más fácil de obtener lo que quieres.

Regla n.o 27: Intenta cuantificar el comportamiento no deseado.

Algunos miembros de tu equipo comenzarán a sentirse frustrados por las propiedades del sistema que no les gusten, ya que la función de pérdida existente no las captura. En este punto, deben hacer lo que sea necesario para convertir sus quejas en números sólidos. Por ejemplo, si creen que se muestran demasiadas "apps de bromas" en la búsqueda de Play, podrían usar evaluadores humanos que identifiquen apps de bromas. (Es posible que puedas usar datos etiquetados manualmente en este caso porque una fracción relativamente pequeña de las consultas representa una gran parte del tráfico). Si tus problemas son medibles, puedes comenzar a usarlos como atributos, objetivos o métricas. La regla general es "medir primero, optimizar después".

Regla n.o 28: Ten en cuenta que el comportamiento idéntico a corto plazo no implica un comportamiento idéntico a largo plazo.

Imagina que tienes un sistema nuevo que analiza cada doc_id y exact_query, y luego calcula la probabilidad de clic para cada documento para cada consulta. Descubres que su comportamiento es casi idéntico a tu sistema actual en comparación con la prueba A/B. Por lo tanto, debido a su simplicidad, lo inicias. Sin embargo, notarás que no se muestran apps nuevas. ¿Por qué? Dado que tu sistema solo muestra un documento basado en su propio historial con esa consulta, no hay forma de saber que se debe mostrar un documento nuevo.

La única forma de entender cómo funciona un sistema a largo plazo es entrenarlo solo con datos adquiridos cuando el modelo está activo. Esto es muy difícil.

Desviación entre el entrenamiento y la publicación

La desviación entre el entrenamiento y la entrega es la diferencia entre el rendimiento del entrenamiento y el de la publicación. Esta desviación puede deberse a los siguientes motivos:

  • Una discrepancia entre cómo manejas los datos en las canalizaciones de entrenamiento y de entrega
  • Un cambio en los datos entre el momento del entrenamiento y el de entrega.
  • Un ciclo de reacción entre el modelo y el algoritmo

Observamos sistemas de aprendizaje automático de producción en Google con una desviación entre el entrenamiento y la entrega que afecta negativamente el rendimiento. La mejor solución es supervisarlo de forma explícita para que los cambios en el sistema y en los datos no generen una desviación inadvertida.

Regla n.o 29: La mejor manera de asegurarte de que el entrenamiento se asemeja a la publicación es guardar el conjunto de atributos que usas en el momento de la entrega y, luego, canalizar esos atributos a un registro para usarlos en el momento del entrenamiento.

Incluso si no puedes hacerlo en cada ejemplo, hazlo por una fracción pequeña, de modo que puedas verificar la coherencia entre la publicación y el entrenamiento (consulta la regla n.o 37). Los equipos que tomaron esta medida en Google a veces se sorprendían con los resultados. La página principal de YouTube pasó a las funciones de registro en el momento de la entrega con mejoras significativas en la calidad y una reducción en la complejidad del código. Además, muchos equipos están cambiando sus infraestructuras.

Regla n.o 30: Datos de muestra con ponderación por importancia, no los quites de forma arbitraria.

Cuando tienes demasiados datos, es tentador tomar los archivos del 1 al 12 e ignorar los archivos del 13 al 99. Esto es un error. Aunque los datos que nunca se mostraron al usuario se pueden descartar, la ponderación por importancia es la mejor opción para el resto. La ponderación por importancia implica que, si decides que usarás el ejemplo X con una probabilidad del 30%, debes aplicar un peso de 10/3. Con la ponderación por importancia, se mantienen todas las propiedades de calibración que analizamos en la regla n.o 14.

Regla n.o 31: Ten en cuenta que si unes datos de una tabla durante el entrenamiento y la publicación, los datos en la tabla pueden cambiar.

Supongamos que unes los ID de documentos con una tabla que contiene atributos para esos documentos (como la cantidad de comentarios o clics). Entre el entrenamiento y la entrega, se pueden cambiar las características en la tabla. La predicción de tu modelo para el mismo documento puede diferir entre el entrenamiento y la entrega. La forma más sencilla de evitar este tipo de problema es registrar los atributos durante la entrega (consulta la regla n.o 32). Si la tabla cambia lentamente, puedes tomar una instantánea de la tabla por hora o por día para obtener datos razonablemente cercanos. Ten en cuenta que esto no resuelve por completo el problema.

Regla n.o 32: Vuelve a usar el código entre la canalización de entrenamiento y la canalización del servidor cuando sea posible.

El procesamiento por lotes es diferente al procesamiento en línea. En el procesamiento en línea, debes manejar cada solicitud a medida que llega (p.ej., debes realizar una búsqueda separada para cada consulta), mientras que, en el procesamiento por lotes, puedes combinar tareas (p.ej., hacer una unión). En la entrega, estás realizando un procesamiento en línea, mientras que el entrenamiento es una tarea de procesamiento por lotes. Sin embargo, hay algunas acciones que puedes realizar para reutilizar el código. Por ejemplo, puedes crear un objeto que sea específico para tu sistema, en el que el resultado de cualquier consulta o unión se puede almacenar de una forma legible y donde los errores se pueden probar con facilidad. Luego, una vez que hayas recopilado toda la información, durante la entrega o el entrenamiento, ejecuta un método común entre el objeto legible legible para tu sistema y el formato que el sistema de aprendizaje automático espera. Esto elimina una fuente de desviación entre el entrenamiento y la entrega. Como corolario, intenta no usar dos lenguajes de programación diferentes entre el entrenamiento y la entrega. Esta decisión hará que sea casi imposible compartir el código.

Regla n.o 33: Si produces un modelo basado en los datos hasta el 5 de enero, prueba el modelo en los datos a partir del 6 de enero.

En general, mide el rendimiento de un modelo en los datos recopilados después de los datos con los que entrenaste el modelo, ya que esto refleja mejor lo que hará tu sistema en producción. Si produces un modelo basado en los datos hasta el 5 de enero, pruébalo en los datos del 6 de enero. Se espera que el rendimiento no sea tan bueno en los datos nuevos, pero no debería ser mucho peor. Dado que puede haber efectos diarios, es posible que no predigas la tasa de clics promedio o el porcentaje de conversiones, pero el área bajo la curva, que representa la probabilidad de darle una puntuación más alta al ejemplo positivo que al ejemplo negativo, debería ser razonablemente cercana.

Regla n.o 34: En la clasificación binaria para filtrado (como la detección de spam o la determinación de correos electrónicos de interés), realiza pequeños sacrificios a corto plazo en el rendimiento para obtener datos muy limpios.

En una tarea de filtrado, los ejemplos que se marcan como negativos no se muestran al usuario. Supongamos que tienes un filtro que bloquea el 75% de los ejemplos negativos durante la entrega. Es posible que te sientas tentado de extraer datos de entrenamiento adicionales de las instancias que se muestran a los usuarios. Por ejemplo, si un usuario marca un correo electrónico como spam que permitió tu filtro, es posible que quieras aprender de esto.

Pero este enfoque introduce un sesgo muestral. Puedes recopilar datos más limpios si, en cambio, durante la entrega indicas que el 1% de todo el tráfico está "retenido" y envías todos los ejemplos retenidos al usuario. Ahora, tu filtro bloquea al menos el 74% de los ejemplos negativos. Estos ejemplos retenidos se pueden convertir en tus datos de entrenamiento.

Ten en cuenta que, si tu filtro bloquea el 95% de los ejemplos negativos o más, este enfoque se vuelve menos viable. Aun así, si deseas medir el rendimiento de entrega, puedes crear una muestra aún más pequeña (por ejemplo, 0.1% o 0.001%). Diez mil ejemplos son suficientes para estimar el rendimiento con bastante precisión.

Regla n.o 35: Ten cuidado con la desviación inherente a los problemas de clasificación.

Cuando cambias el algoritmo de clasificación lo suficiente como para mostrar resultados diferentes, cambiaste de manera efectiva los datos que el algoritmo verá en el futuro. Este tipo de desviación aparecerá y deberías diseñar tu modelo a su alrededor. Existen varios enfoques diferentes. Estos enfoques son todas formas de favorecer los datos que tu modelo ya vio.

  1. Tener una regularización más alta en los atributos que cubren más consultas, a diferencia de los atributos que solo están en una consulta. De esta manera, el modelo favorecerá los atributos específicos de una o varias consultas por sobre los atributos que se generalizan en todas las consultas. Este enfoque puede ayudar a evitar que los resultados muy populares acaben en consultas irrelevantes. Ten en cuenta que esto es contrario a la sugerencia más convencional de contar con más regularización en columnas de atributos con valores más únicos.
  2. Solo permite que los atributos tengan ponderaciones positivas. Por lo tanto, cualquier atributo bueno será mejor que uno que sea "desconocido".
  3. No uses atributos solo de documentos. Esta es una versión extrema de la versión 1. Por ejemplo, incluso si una app determinada es una descarga popular, más allá de la consulta, no es necesario mostrarla en todos lados. Esto se simplifica al no tener atributos solo de documentos. La razón por la que no deseas mostrar una app popular específica en todos lados está relacionada con la importancia de lograr que las apps que deseas que estén disponibles lo estén. Por ejemplo, si alguien busca "app para observar aves", es posible que descargue "pájaros enojados", pero ese no era su objetivo. Si se muestra esta app, es posible que mejore la tasa de descarga, pero no se cumplen las necesidades del usuario.

Regla n.o 36: Evita los bucles de retroalimentación con las características posicionales.

La posición del contenido afecta considerablemente la probabilidad de que el usuario interactúe con él. Si colocas una app en la primera posición, se seleccionará con más frecuencia y te dará la impresión de que es más probable que se seleccione. Una forma de manejar esto es agregar atributos posicionales, es decir, atributos sobre la posición del contenido en la página. Entrenas tu modelo con atributos posicionales, y este aprende a ponderar, por ejemplo, al atributo "1stposition" (posición). Por lo tanto, tu modelo da menos peso a otros factores para ejemplos con “1stposition=true”. Luego, en la publicación, no asignas ninguna instancia al atributo posicional o les asignas el mismo atributo predeterminado, porque estás puntuando a los candidatos antes de que hayas decidido el orden en el que se mostrarán.

Ten en cuenta que es importante mantener cualquier atributo de posición separado del resto del modelo debido a esta asimetría entre el entrenamiento y la prueba. Lo ideal es que el modelo sea la suma de una función de los atributos posicionales y una función del resto de los atributos. Por ejemplo, no cruces los atributos de posición con ningún atributo de documento.

Regla n.o 37: Mide la desviación entre el entrenamiento y la publicación.

Existen varios elementos que pueden causar sesgo en el sentido más general. Además, puedes dividirlo en varias partes:

  • La diferencia entre el rendimiento en los datos de entrenamiento y los datos de exclusión. En general, esto siempre existe y no siempre es malo.
  • La diferencia entre el rendimiento en los datos de exclusión y los datos de "al día siguiente". Nuevamente, esto siempre existirá. Debes ajustar la regularización para maximizar el rendimiento del día siguiente. Sin embargo, las grandes caídas en el rendimiento entre los datos retenidos y los datos del día siguiente pueden ser un indicador de que algunos atributos dependen del tiempo y posiblemente afecten al rendimiento del modelo de forma negativa.
  • La diferencia entre el rendimiento en los datos del día siguiente y los datos en vivo. Si aplicas un modelo a un ejemplo en los datos de entrenamiento y el mismo ejemplo en la publicación, deberías obtener el mismo resultado (consulta la regla n.o 5). Por lo tanto, una discrepancia aquí indica, probablemente, un error de ingeniería.

Fase III de aprendizaje automático: Crecimiento reducido, refinamiento de la optimización y modelos complejos

Existen ciertos indicios de que la segunda fase llega a su fin. Primero, las ganancias mensuales comenzarán a disminuir. Comenzarás a tener compensaciones entre las métricas: verás que algunas aumentan y otras disminuyen en algunos experimentos. Aquí es donde se vuelve interesante. Debido a que los beneficios son más difíciles de lograr, el aprendizaje automático debe volverse más sofisticado. Una advertencia: esta sección tiene más reglas de cielo azul que las secciones anteriores. Hemos visto a muchos equipos pasar por los momentos felices de la fase I y la fase II del aprendizaje automático. Una vez que alcanzan la Fase III, los equipos deben encontrar su propia ruta.

Regla n.o 38: No pierdas tiempo en nuevos atributos si los objetivos no alineados son un problema.

A medida que tu meseta de mediciones, tu equipo comenzará a buscar problemas que estén fuera del alcance de los objetivos de tu sistema de aprendizaje automático actual. Como se mencionó anteriormente, si los objetivos del producto no están cubiertos por el objetivo algorítmico existente, debes cambiar el objetivo o los objetivos del producto. Por ejemplo, puedes optimizar los clics, los +1 o las descargas, pero debes tomar decisiones de lanzamiento según los evaluadores humanos.

Regla n.o 39: Las decisiones de lanzamiento representan los objetivos a largo plazo del producto.

Alice tiene una idea para reducir la pérdida logística de las predicciones de instalaciones. Agrega un atributo. La pérdida logística disminuye. Cuando realiza un experimento en vivo, observa un aumento en la tasa de instalación. Sin embargo, cuando va a una reunión de revisión de lanzamientos, alguien señala que la cantidad de usuarios activos diarios disminuye un 5%. El equipo decide no lanzar el modelo. Alice está decepcionada, pero ahora se da cuenta de que las decisiones de lanzamiento dependen de varios criterios y que solo algunos de ellos pueden optimizarse directamente con el AA.

La verdad es que el mundo real no es un juego de rol; no hay "puntos de éxito" que identifican el estado de tu producto. El equipo debe usar las estadísticas que reúne para intentar predecir de forma efectiva qué tan bueno será el sistema en el futuro. Deben preocuparse por la participación, los usuarios activos por 1 día (DAU), los 30 DAU, los ingresos y el retorno de la inversión del anunciante. Estas métricas que se pueden medir en las pruebas A/B son solo un proxy de los objetivos a más largo plazo: satisfacer a los usuarios, aumentar la cantidad de usuarios, satisfacer a los socios y generar ganancias, lo que incluso podría considerar proxies para tener un producto útil de alta calidad y una empresa próspera en cinco años.

Las únicas decisiones de lanzamiento sencillas son cuando todas las métricas mejoran (o, al menos, no empeoran). Si el equipo puede elegir entre un algoritmo de aprendizaje automático sofisticado o una simple heurística, si la heurística simple hace un mejor trabajo en todas estas métricas, debe elegir la heurística. Además, no hay una clasificación explícita para todos los valores de métrica posibles. En particular, considera las siguientes dos situaciones:

Experimento Usuarios activos por día Ingresos/día
A 1 millón USD 4 millones
B 2 millones USD 2 millones

Si el sistema actual es A, es poco probable que el equipo cambie a B. Si el sistema actual es B, entonces es poco probable que el equipo cambie a A. Esto parece entrar en conflicto con el comportamiento racional; sin embargo, las predicciones de las métricas cambiantes pueden o no extenderse y, por lo tanto, hay un gran riesgo con cualquiera de los cambios. Cada métrica abarca un riesgo que le preocupa al equipo.

Además, ninguna métrica cubre la preocupación principal del equipo, "¿dónde estará mi producto dentro de cinco años?".

Por otro lado, las personas tienden a favorecer un objetivo que pueden optimizar directamente. La mayoría de las herramientas de aprendizaje automático favorecen ese entorno. Un ingeniero que incorpora nuevas funciones puede obtener un flujo constante de lanzamientos en ese entorno. Existe un tipo de aprendizaje automático, el aprendizaje de varios objetivos, que comienza a abordar este problema. Por ejemplo, se puede formular un problema de satisfacción de restricciones que tenga límites inferiores en cada métrica y se optimice una combinación lineal de métricas. Sin embargo, incluso en ese caso, no todas las métricas se enmarcan fácilmente como objetivos de aprendizaje automático: si se hace clic en un documento o se instala una app, es porque se mostró el contenido. Sin embargo, es mucho más difícil determinar por qué un usuario visita tu sitio. Cómo predecir el éxito futuro de un sitio de forma integral es IA-completo: tan difícil como la visión por computadora o el procesamiento de lenguajes naturales.

Regla n.o 40: Mantén los conjuntos simples.

Los modelos unificados que aceptan atributos sin procesar y clasifican contenido directamente son los modelos más fáciles de depurar y comprender. Sin embargo, un conjunto de modelos (un "modelo" que combina las puntuaciones de otros modelos) puede funcionar mejor. Para mantener la simplicidad, cada modelo debe ser un ensamble que solo tome la entrada de otros modelos o un modelo base que tome muchas funciones, pero no ambas. Si tienes modelos sobre otros modelos que se entrenan por separado, combinarlos puede generar un comportamiento inadecuado.

Usa un modelo simple para el ensamble que tome solo las salidas de tus modelos "básicos" como entradas. También debes aplicar propiedades en estos modelos de conjuntos. Por ejemplo, un aumento en la puntuación que produce un modelo base no debe disminuir la puntuación del conjunto. Además, es mejor si los modelos entrantes se pueden interpretar de forma semántica (por ejemplo, calibrados), para que los cambios de los modelos subyacentes no confundan el modelo de ensamble. Además, aplica que un aumento en la probabilidad predicha de un clasificador subyacente no disminuya la probabilidad predicha del conjunto.

Regla n.o 41: Cuando el rendimiento se estanca, busca nuevas fuentes de información de forma cualitativa para agregar, en lugar de definir mejor las señales existentes.

Agregaste cierta información demográfica sobre el usuario. Agregaste información sobre las palabras del documento. Completaste la exploración de plantillas y ajustaste la regularización. No observaste un lanzamiento con más de un 1% de mejora en las métricas clave en unos pocos trimestres. ¿Cuál es el próximo paso?

Es hora de comenzar a compilar la infraestructura para atributos radicalmente diferentes, como el historial de los documentos a los que este usuario accedió en el último día, semana o año, o los datos de una propiedad diferente. Usa entidades de wikidatos o algún recurso interno de tu empresa (como el gráfico de conocimiento de Google). Usa el aprendizaje profundo. Comienza a ajustar tus expectativas sobre el retorno de la inversión que esperas y expande tus esfuerzos según corresponda. Como en cualquier proyecto de ingeniería, debes comparar el beneficio de agregar atributos nuevos con el costo de una mayor complejidad.

Regla n.o 42: No esperes que la diversidad, la personalización o la relevancia estén relacionadas con la popularidad tanto como crees.

La diversidad en un conjunto de contenidos puede significar muchas cosas; la más común es la diversidad de la fuente del contenido. La personalización implica que cada usuario obtiene sus propios resultados. La relevancia implica que los resultados para una consulta en particular son más apropiados para esa consulta que para cualquier otra. Por lo tanto, estas tres propiedades se definen como diferentes de las comunes.

El problema es que lo común tiende a ser más difícil de superar.

Ten en cuenta que tu sistema mide clics, el tiempo dedicado, reproducciones, +1, veces que se comparte el contenido, etc., es decir, la popularidad del contenido. A veces, los equipos intentan aprender un modelo personal con diversidad. Para hacerlo, agregan funciones que le permitirían al sistema personalizar (algunas funciones que representen el interés del usuario) o diversificar (atributos que indiquen si este documento tiene características en común con otros documentos mostrados, como el autor o contenido), y descubren que esas características tienen menos peso (o, a veces, un signo diferente) de lo que esperan.

Esto no significa que la diversidad, la personalización o la relevancia no sean valiosas. Como se mencionó en la regla anterior, puedes realizar un procesamiento posterior para aumentar la diversidad o la relevancia. Si observas que los objetivos a largo plazo aumentan, puedes declarar que la diversidad o la relevancia son valiosas, además de la popularidad. Luego, puedes continuar usando tu procesamiento posterior o modificar directamente el objetivo según la diversidad o la relevancia.

Regla n.o 43: Tus amigos tienden a ser los mismos en diferentes productos. Tus intereses no suelen ser así.

Los equipos de Google están muy interesados en tomar un modelo que prediga la cercanía de una conexión en un producto y que funcione bien en otro. Tus amigos son como son. Por otro lado, vi a varios equipos tener dificultades con las funciones de personalización en divisiones de productos. Sí, parece que debería funcionar. Por ahora, parece que no. A veces, lo que funciona es usar datos sin procesar de una propiedad para predecir el comportamiento en otra. Además, ten en cuenta que puede ser útil saber que un usuario tiene un historial en otra propiedad. Por ejemplo, la presencia de actividad del usuario en dos productos puede ser un indicativo en sí misma.

Existen muchos documentos sobre el aprendizaje automático en Google y en el exterior.

Agradecimientos

Agradecimientos a David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Lind Anders y Shanie Anders. Gracias también a Kristen Lefevre, Suddha Basu y Chris Berg, quienes nos ayudaron con una versión anterior. Cualquier error, omisión o (¡gasto!) las opiniones impopulares son mías.

Apéndice

En este documento, se incluyen diversas referencias a los productos de Google. Para proporcionar más contexto, agregué una descripción breve de los ejemplos más comunes a continuación.

Descripción general de YouTube

YouTube es un servicio de transmisión de videos. Tanto los equipos de Ver a continuación como de Página principal de YouTube usan modelos de AA para clasificar las recomendaciones de videos. Ver a continuación recomienda videos para mirar después de uno que está reproduciendo, mientras que Página principal recomienda videos a los usuarios que navegan en la página principal.

Descripción general de Google Play

Google Play tiene muchos modelos que resuelven diversos problemas. Las apps de la Búsqueda de Play, las recomendaciones personalizadas en la página principal de Play y la opción "Usuarios también instalados" usan aprendizaje automático.

Descripción general de Google+

Google+ usó el aprendizaje automático en varias situaciones: clasificar las publicaciones en las "novedades" de las que el usuario ve, clasificar las publicaciones de "Lo más interesante" (las publicaciones que son muy populares ahora), clasificar a las personas que conoces, etc. Google Plus cerró todas las cuentas personales en 2019 y se reemplazó por Google Currents para las cuentas comerciales el 6 de julio de 2020.