Reglas del aprendizaje automático:

Prácticas recomendadas para la ingeniería de AA

Martin Zinkevich

El objetivo de este documento es ayudar a quienes tienen conocimientos básicos del aprendizaje automático a aprovechar las prácticas recomendadas de Google en este campo. Presenta un estilo para el aprendizaje automático, similar a la Guía de estilo de C++ de Google y otras guías populares de programación práctica. Si cursaste una clase de aprendizaje automático o compilaste o trabajaste en un modelo de aprendizaje automático, tienes los conocimientos necesarios para leer este documento.

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

Terminología

Los siguientes términos aparecerán de forma reiterada en nuestro análisis del aprendizaje automático efectivo:

  • Instancia: Es el aspecto sobre el que deseas hacer una predicción. Por ejemplo, la instancia podría ser una página web que deseas clasificar como "sobre gatos" o "no sobre gatos".
  • Etiqueta: Es una respuesta para una tarea de predicción, ya sea la respuesta que produce un sistema de aprendizaje automático o la respuesta correcta proporcionada en los datos de entrenamiento. Por ejemplo, la etiqueta de una página web podría ser "sobre gatos".
  • Atributo: Es una propiedad de una instancia que se usa en una tarea de predicción. Por ejemplo, una página web podría tener el atributo "contiene la palabra "gato".
  • Columna de atributos: Es un conjunto de atributos relacionados, como el conjunto de todos los países posibles en los que podrían vivir los usuarios. Un ejemplo puede tener una o más características presentes en una columna de atributos. "Columna de atributos" es 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: Es una representación estadística de una tarea de predicción. Entrenas un modelo con ejemplos y, luego, lo usas para hacer predicciones.
  • Métrica: Es un número importante para ti. Puede o no estar optimizado directamente.
  • Objetivo: Es una métrica que tu algoritmo intenta optimizar.
  • Canalización: Es la infraestructura que rodea un algoritmo de aprendizaje automático. Incluye recopilar los datos del frontend, colocarlos en archivos de datos de entrenamiento, entrenar uno o más modelos y exportarlos a producción.
  • Tasa de clics: Es el porcentaje de visitantes de una página web que hacen clic en un vínculo de un anuncio.

Descripción general

Para crear productos de calidad, sigue estos pasos:

hacer el aprendizaje automático como el gran ingeniero que eres, no como el gran experto en aprendizaje automático que no eres

La mayoría de los problemas que enfrentarás son, en realidad, 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 funciones excelentes, no de algoritmos de aprendizaje automático excelentes. Por lo tanto, el enfoque básico es el siguiente:

  1. Asegúrate de que tu canalización sea sólida de extremo a extremo.
  2. Comienza con un objetivo razonable.
  3. Agrega funciones lógicas de forma sencilla.
  4. Asegúrate de que tu canalización siga siendo sólida.

Este enfoque funcionará bien durante un período prolongado. Desvíate de este enfoque solo cuando no haya más trucos simples que te permitan avanzar. Agregar complejidad ralentiza los lanzamientos futuros.

Una vez que hayas agotado los trucos simples, es posible que el aprendizaje automático de vanguardia sea tu futuro. Consulta la sección sobre proyectos de aprendizaje automático de la Fase III.

Este documento está organizado de la siguiente manera:

  1. La primera parte debería ayudarte a comprender si es el momento adecuado para crear un sistema de aprendizaje automático.
  2. La segunda parte trata sobre la implementación de tu primera canalización.
  3. La tercera parte trata sobre el lanzamiento y la iteración mientras se agregan funciones nuevas a tu canalización, cómo evaluar modelos y la desviación entre el entrenamiento y la entrega.
  4. La parte final trata sobre qué hacer cuando llegas a un punto de inflexión.
  5. Luego, hay una lista de trabajos relacionados y un anexo con algunos antecedentes sobre los sistemas que se suelen usar como ejemplos en este documento.

Antes del aprendizaje automático

Regla n.° 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 esto tenga un rendimiento inferior a las heurísticas básicas. Si crees que el aprendizaje automático te dará un aumento del 100%, una heurística te llevará al 50% del camino.

Por ejemplo, si clasificas apps en un mercado de aplicaciones, puedes usar la tasa de instalación o la cantidad de instalaciones como heurísticas. Si detectas spam, filtra a los publicadores que hayan enviado spam anteriormente. Tampoco tengas miedo de usar la edición manual. Si necesitas clasificar los contactos, coloca en primer lugar los que usaste más recientemente (o incluso clasifícalos alfabéticamente). Si el aprendizaje automático no es absolutamente necesario para tu producto, no lo uses hasta que tengas datos.

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

Antes de formalizar lo que hará tu sistema de aprendizaje automático, haz un seguimiento de todo lo posible en tu sistema actual. Hazlo por los siguientes motivos:

  1. Es más fácil obtener permiso de los usuarios del sistema con anticipación.
  2. Si crees que algo podría ser un problema en el futuro, es mejor obtener datos históricos ahora.
  3. Si diseñas tu sistema teniendo en cuenta la instrumentación de métricas, todo irá mejor en el futuro. Específicamente, no quieres buscar cadenas en los registros para instrumentar tus métricas.
  4. Notarás qué elementos cambian y cuáles permanecen iguales. Por ejemplo, supongamos que quieres optimizar directamente los usuarios activos por un día. Sin embargo, durante las primeras manipulaciones del sistema, es posible que notes que las alteraciones drásticas de la experiencia del usuario no cambian de manera notable esta métrica.

El equipo de Google Plus mide las expansiones por lectura, las veces que se vuelve a compartir por lectura, los Me gusta por lectura, los comentarios por lectura, los comentarios por usuario, las veces que se vuelve a compartir por usuario, etc., que usan para calcular la calidad de una publicación en el momento de la publicación. Además, ten en cuenta que es importante contar con un marco de trabajo experimental en el que puedas agrupar a los usuarios en segmentos y agregar estadísticas por experimento. Consulta la regla n° 12.

Si eres más flexible en la recopilación de métricas, puedes obtener un panorama más amplio de tu sistema. ¿Notas algún problema? Agrega una métrica para hacer un seguimiento. ¿Te entusiasma un cambio cuantitativo en la última versión? Agrega una métrica para hacer un seguimiento.

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

Una heurística simple puede hacer que tu producto salga a la luz. Una heurística compleja es inmantenible. Una vez que tengas datos y una idea básica de lo que intentas lograr, continúa con el aprendizaje automático. Como en la mayoría de las tareas de ingeniería de software, querrás actualizar constantemente tu enfoque, ya sea una heurística o un modelo de aprendizaje automático, y descubrirás que el modelo de aprendizaje automático es más fácil de actualizar y mantener (consulta la regla n° 16).

Fase I de AA: Tu primera canalización

Enfócate 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 descubrir qué sucede si primero no confías en tu canalización.

Regla n° 4: Mantén el primer modelo simple y elige la infraestructura adecuada.

El primer modelo proporciona el mayor impulso a tu producto, por lo que no es necesario que sea sofisticado. Sin embargo, te encontrarás con muchos más problemas de infraestructura de los que esperas. Antes de que alguien pueda usar tu nuevo y sofisticado sistema de aprendizaje automático, debes determinar lo siguiente:

  • Cómo obtener ejemplos para tu algoritmo de aprendizaje
  • Un primer corte de lo que significa "bueno" y "malo" para tu sistema.
  • Cómo integrar tu modelo en tu aplicación Puedes aplicar el modelo en vivo o precalcularlo en ejemplos sin conexión y almacenar los resultados en una tabla. Por ejemplo, es posible que desees preclasificar las páginas web y almacenar los resultados en una tabla, pero también es posible que desees clasificar los mensajes de chat en vivo.

Elegir funciones simples facilita lo siguiente:

  • Las funciones llegan a tu algoritmo de aprendizaje correctamente.
  • El modelo aprende pesos razonables.
  • Las funciones llegan a tu modelo en el servidor correctamente.

Una vez que tengas un sistema que haga estas tres tareas de forma confiable, habrás hecho 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 buscan un primer lanzamiento “neutral”, es decir, un primer lanzamiento que de prioridad explícitamente a las ganancias del aprendizaje automático para evitar distracciones.

Regla n.° 5: Prueba la infraestructura de forma independiente 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 a su alrededor. En particular, haz lo siguiente:

  1. Prueba cómo ingresar datos al algoritmo. Verifica que se hayan propagado las columnas de atributos que deberían propagarse. Cuando la privacidad lo permita, inspecciona manualmente la entrada de tu algoritmo de entrenamiento. Si es posible, verifica las estadísticas de tu canalización en comparación con las estadísticas de los mismos datos procesados en otro lugar.
  2. Prueba cómo obtener modelos del algoritmo de entrenamiento. Asegúrate de que el modelo de tu entorno de entrenamiento tenga la misma puntuación que el modelo de tu entorno de publicación (consulta la regla n° 37).

El aprendizaje automático tiene un elemento de imprevisibilidad, por lo que debes asegurarte de que tengas pruebas para el código para crear ejemplos en el entrenamiento y la entrega, y que puedas cargar y usar un modelo fijo durante la entrega. Además, es importante que comprendas tus datos. Consulta Sugerencias prácticas para el análisis de conjuntos de datos grandes y complejos.

Regla n° 6: Ten cuidado con los datos que se pierden cuando copias canalizaciones.

A menudo, para crear una canalización, copiamos una existente (es decir, programación de culto a la carga) y la canalización anterior descarta los datos que necesitamos para la nueva. Por ejemplo, la canalización de Contenido destacado de Google Plus descarta las publicaciones más antiguas (porque intenta clasificar las publicaciones recientes). Esta canalización se copió para usarla en el flujo de Google Plus, donde las publicaciones más antiguas siguen siendo relevantes, pero la canalización seguía publicando publicaciones antiguas. Otro patrón común es registrar solo los datos que vio el usuario. Por lo tanto, estos datos son inútiles si queremos modelar por qué el usuario no vio una publicación en particular, ya que se descartaron todos los ejemplos negativos. Se produjo un problema similar en Play. Mientras se trabajaba en Play Apps Home, se creó una nueva canalización que también contenía ejemplos de la página de destino de Play Juegos sin ninguna función para desambiguar de dónde provenía cada ejemplo.

Regla n° 7: Convierte las heurísticas en funciones o manéjalas de forma externa.

Por lo general, los problemas que el aprendizaje automático intenta resolver no son completamente nuevos. Existe un sistema existente para clasificar o ordenar, o cualquier problema que intentes resolver. Esto significa que hay muchas reglas y heurísticas. Estas mismas heurísticas pueden ayudarte cuando se ajustan con el aprendizaje automático. Tus heurísticas deben extraerse para obtener cualquier información que tengan por dos razones. En primer lugar, la transición a un sistema de aprendizaje automático será más fluida. En segundo lugar, por lo general, esas reglas contienen mucha de la intuición sobre el sistema que no quieres descartar. Existen cuatro maneras de usar una heurística existente:

  • Preprocesa los datos con la heurística. Si la función es increíble, esta es una opción. Por ejemplo, si, en un filtro de spam, el remitente ya está en la lista de entidades bloqueadas, no intentes volver a aprender qué significa “lista de entidades bloqueadas”. Bloquear el mensaje Este enfoque tiene más sentido en las tareas de clasificación binaria.
  • Crea un atributo. Crear directamente un componente a partir de la heurística es muy útil. Por ejemplo, si usas una heurística para calcular una puntuación de relevancia para un resultado de la 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 modificar el valor (por ejemplo, convertirlo en uno de un conjunto finito de valores discretos o combinarlo con otras características), pero comienza por usar el valor sin procesar que produce la heurística.
  • Extrae las entradas sin procesar de la heurística. Si hay una heurística para apps que combina la cantidad de instalaciones, la cantidad de caracteres en el texto y el día de la semana, considera separar estos elementos y enviar estas entradas al aprendizaje por separado. Algunas técnicas que se aplican a los conjuntos también se aplican aquí (consulta la regla n° 40).
  • Modifica la etiqueta. Esta es una opción cuando crees que la heurística captura información que no se incluye actualmente en la etiqueta. Por ejemplo, si intentas maximizar la cantidad de descargas, pero también quieres contenido de calidad, tal vez la solución sea multiplicar la etiqueta por la cantidad promedio de estrellas que recibió la app. Hay mucho margen de maniobra. Consulta "Tu primer objetivo".

Ten en cuenta la complejidad adicional cuando uses heurísticas en un sistema de IA. El uso de heurísticas antiguas en tu nuevo algoritmo de aprendizaje automático puede ayudar a crear una transición fluida, pero piensa si hay una forma más sencilla de lograr el mismo efecto.

Supervisión

En general, practica una buena higiene de las alertas, como hacer que las alertas sean prácticas y tener una página del panel.

Regla n° 8: Conoce los requisitos de actualización de tu sistema.

¿En qué medida se degrada el rendimiento si tienes un modelo de un día? ¿Una semana? ¿Un cuarto de siglo? Esta información puede ayudarte a comprender las prioridades de tu supervisión. Si pierdes calidad de producto significativa si el modelo no se actualiza durante un día, tiene sentido que un ingeniero lo supervise de forma continua. La mayoría de los sistemas de publicación de anuncios tienen anuncios nuevos para controlar todos los días y deben actualizarse a diario. Por ejemplo, si no se actualiza el modelo de IA de la Búsqueda de Google Play, puede tener un impacto negativo en menos de un mes. Algunos modelos de Contenido destacado en Google Plus no tienen identificador de publicación, por lo que no se pueden exportar con frecuencia. Otros modelos que tienen identificadores de publicaciones se actualizan con mucha más frecuencia. Además, ten en cuenta que la actualización puede cambiar con el tiempo, especialmente cuando se agregan o quitan columnas de atributos de tu modelo.

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

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

Realiza verificaciones de coherencia justo antes de exportar el modelo. Específicamente, asegúrate de que el rendimiento del modelo sea razonable en los datos retenidos. O bien, si tienes dudas persistentes con los datos, no exportes un modelo. Muchos equipos que implementan modelos de forma continua verifican el área bajo la curva ROC (o AUC) antes de exportarlos. Los problemas relacionados con los modelos que no se exportaron requieren una alerta por correo electrónico, pero los problemas en un modelo para el usuario pueden requerir una página. Por lo tanto, es mejor esperar y asegurarse antes de que afecte a los usuarios.

Regla n° 10: Observa si hay fallas silenciosas.

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 seguirá siendo bastante bueno, degradándose gradualmente. A veces, encuentras tablas que están desactualizadas hace meses, y una simple actualización mejora el rendimiento más que cualquier otro lanzamiento de ese trimestre. La cobertura de una función puede cambiar debido a 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. Play tuvo una tabla que no se actualizaba desde hacía 6 meses, y solo actualizarla proporcionó un aumento del 2% en el porcentaje de instalaciones. Si realizas un seguimiento de las estadísticas de los datos y, además, los inspeccionas manualmente de vez en cuando, puedes reducir este tipo de fallas.

Regla n° 11: Asigna propietarios y documentación a las columnas de atributos.

Si el sistema es grande y hay muchas columnas de componentes, averigua quién creó o mantiene cada columna de componentes. 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 bueno tener una descripción más detallada de qué es la función, de dónde proviene y de cómo se espera que ayude.

Tu primer objetivo

Tienes muchas métricas o mediciones sobre el sistema que te interesan, pero tu algoritmo de aprendizaje automático a menudo requerirá un solo objetivo, un número que el algoritmo “intenta” optimizar. Aquí distingo entre objetivos y métricas: una métrica es cualquier número que informa tu sistema, que puede ser importante o no. Consulta también la regla n° 2.

Regla n° 12: No analices demasiado el objetivo que elijas para optimizar directamente.

Quieres ganar dinero, hacer felices a tus usuarios y hacer del mundo un lugar mejor. Hay muchas métricas que te interesan y debes medirlas todas (consulta la regla n° 2). Sin embargo, al principio del proceso de aprendizaje automático, notarás que todos aumentan, incluso aquellos que no optimizas directamente. Por ejemplo, supongamos que te interesa la cantidad de clics y el tiempo que se pasa en el sitio. Si optimizas para la cantidad de clics, es probable que observes un aumento en el tiempo en la página.

Por lo tanto, no compliques las cosas y no te preocupes demasiado por equilibrar las diferentes métricas cuando aún puedes aumentar todas fácilmente. Sin embargo, no lleves esta regla demasiado lejos: no confundas tu objetivo con el estado final del sistema (consulta la regla n° 39). Además, si aumentas la métrica optimizada directamente, pero decides no lanzarla, es posible que debas revisar los objetivos.

Regla n° 13: Elige una métrica simple, observable y atribuible para tu primer objetivo.

A menudo, no sabes cuál es el verdadero objetivo. Crees que lo sabes, pero, luego, cuando miras los datos y el análisis en paralelo de tu sistema anterior y el nuevo sistema de AA, te das cuenta de que quieres ajustar el objetivo. Además, a menudo, los diferentes miembros del equipo no pueden ponerse de acuerdo sobre el verdadero objetivo. El objetivo de IA debe ser algo fácil de medir y ser un proxy del objetivo “real”. De hecho, a menudo no hay un objetivo "verdadero" (consulta la regla n° 39). Por lo tanto, entrena con el objetivo de IA simple y considera tener una "capa de políticas" en la parte superior que te permita agregar lógica adicional (con suerte, muy simple) para realizar la clasificación final.

Lo más fácil de modelar es un comportamiento del usuario 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ó este objeto clasificado, se le respondió o se le envió por correo electrónico?
  • ¿Se calificó este objeto clasificado?
  • ¿Se marcó este objeto como spam, pornografía o ofensivo?

Evita modelar los efectos indirectos al principio:

  • ¿El usuario volvió a visitar el sitio al día siguiente?
  • ¿Cuánto tiempo visitó el usuario el sitio?
  • ¿Cuántos usuarios activos por día hubo?

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

Por último, no intentes que el aprendizaje automático averigüe lo siguiente:

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

Todos estos aspectos son importantes, pero también muy difíciles de medir. En su lugar, usa proxies: si el usuario está conforme, permanecerá en el sitio por más tiempo. Si el usuario está satisfecho, volverá a visitar la página mañana. En lo que respecta al bienestar y la salud de la empresa, se requiere el juicio humano para conectar cualquier objetivo de aprendizaje automático con la naturaleza del producto que vendes y tu plan de negocios.

Regla n° 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 motivadas por un modelo probabilístico. Cada predicción se puede interpretar como una probabilidad o un valor esperado. Esto facilita su depuración en comparación con los modelos que usan objetivos (pérdida cero-uno, varias pérdidas de bisagra, etcétera) 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 previstas en las comparaciones o a través de 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, hay subconjuntos de los datos en los que la expectativa promedio predicha es igual a la etiqueta promedio (calibrada en el 1er momento o solo calibrada). Esto es cierto si no tienes ninguna regularización y si tu algoritmo convergió, y es aproximadamente cierto en general. Si tienes un atributo que es 1 o 0 para cada ejemplo, entonces se calibra el conjunto de 3 ejemplos en los que ese atributo es 1. Además, si tienes un atributo que es 1 para cada ejemplo, el conjunto de todos los ejemplos está calibrado.

Con modelos simples, es más fácil lidiar con los ciclos de reacción (consulta la regla n° 36). A menudo, usamos estas predicciones probabilísticas para tomar decisiones, p. ej., clasificar las publicaciones en orden decreciente de valor esperado (es decir, probabilidad de clic, descarga, etcétera). Sin embargo, recuerda que, cuando llegue el momento de elegir qué modelo usar, la decisión es más importante que la probabilidad de los datos dados al modelo (consulta la regla n° 27).

Regla n° 15: Separar el filtrado de spam y la clasificación de calidad en una capa de políticas

La clasificación de calidad es un arte, pero el filtrado de spam es una guerra. Los indicadores que usas para determinar las publicaciones de alta calidad serán evidentes para quienes usen tu sistema y modificarán sus publicaciones para que tengan estas propiedades. Por lo tanto, tu clasificación de calidad debe enfocarse en clasificar el contenido que se publica de buena fe. No debes descartar el algoritmo de aprendizaje del ranking de calidad por clasificar el spam con una puntuación alta. Del mismo modo, el contenido "sexualmente explícito" debe tratarse por separado del Ranking de calidad. El filtrado de spam es otra historia. Debes esperar que las funciones que debes generar cambien constantemente. A menudo, habrá reglas obvias que ingreses en el sistema (si una publicación tiene más de tres votos de spam, no la recuperes, etcétera). Cualquier modelo aprendido se deberá actualizar a diario, si no más rápido. La reputación del creador del contenido será muy importante.

En algún nivel, se deberá integrar el resultado de estos dos sistemas. Ten en cuenta que filtrar el spam en los resultados de la búsqueda probablemente deba ser más estricto que filtrar el spam en los mensajes de correo electrónico. Además, es una práctica estándar quitar el spam de los datos de entrenamiento del clasificador de calidad.

AA, fase II: Ingeniería de atributos

En la primera fase del ciclo de vida de un sistema de aprendizaje automático, los aspectos importantes son ingresar los datos de entrenamiento en el sistema de aprendizaje, instrumentar las métricas de interés y crear una infraestructura de publicación. Después de que tengas un sistema de extremo a extremo en funcionamiento con pruebas de unidades y del sistema instrumentadas, comienza la fase II.

En la segunda fase, hay muchas oportunidades fáciles de aprovechar. Hay una variedad de funciones obvias que se podrían incorporar al sistema. Por lo tanto, la segunda fase del aprendizaje automático implica extraer tantas características como sea posible y combinarlas de maneras intuitivas. Durante esta fase, todas las métricas deberían seguir aumentando. Habrá muchos lanzamientos, y es un buen momento para contar con muchos ingenieros que puedan unir todos los datos que necesitas para crear un sistema de aprendizaje realmente asombroso.

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

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

  • Estás creando nuevas funciones.
  • Estás ajustando la regularización y combinando funciones anteriores de nuevas maneras.
  • Estás ajustando el objetivo.

Independientemente de esto, es bueno dedicarle un poco de atención al modelo: revisar los datos que se ingresan en el ejemplo puede ayudar a encontrar indicadores nuevos, así como indicadores antiguos y dañados. 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 su exactitud. Piensa si es posible tener dos o tres copias ejecutándose en paralelo. Por último, no te preocupes si la función 16 de 35 llega a esta versión de la canalización. Lo obtendrás el próximo trimestre.

Regla n° 17: Comienza con las características observadas y registradas directamente en lugar de las características aprendidas.

Este puede ser un punto controvertido, pero evita muchos problemas. En primer lugar, describamos qué es un atributo aprendido. Un atributo aprendido es un atributo que genera un sistema externo (como un sistema de agrupamiento no supervisado) o el propio aprendiz (p.ej., a través de un modelo factorizado o de aprendizaje profundo). Ambas 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 una función, recuerda que este sistema tiene su propio objetivo. Es posible que el objetivo del sistema externo solo esté correlacionado de manera débil con tu objetivo actual. Si tomas una instantánea del sistema externo, es posible que se desactualice. Si actualizas los atributos desde el sistema externo, es posible que los significados cambien. Si usas un sistema externo para proporcionar una función, ten en cuenta que este enfoque requiere mucho cuidado.

El principal problema con los modelos factorizados y los modelos 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 los mínimos locales que se encuentran en cada iteración pueden ser diferentes. Esta variación dificulta juzgar si el impacto de un cambio en tu sistema es significativo o aleatorio. Si creas un modelo sin atributos profundos, puedes obtener un excelente rendimiento de referencia. Después de lograr este punto de referencia, puedes probar enfoques más esotéricos.

Regla n° 18: Explora con características de contenido que se generalicen en todos los contextos.

A menudo, un sistema de aprendizaje automático es una pequeña parte de un panorama mucho más amplio. Por ejemplo, si imaginas una publicación que podría usarse en Contenido destacado, muchas personas la recomendarán, la volverán a compartir o comentarán antes de que se muestre en Contenido destacado. Si le proporcionas esas estadísticas al alumno, puede promocionar publicaciones nuevas para las que no tiene datos en el contexto que está optimizando. La función Mirar a continuación de YouTube podría usar la cantidad de reproducciones o reproducciones conjuntas (registros de cuántas veces se miró un video después de otro) de la búsqueda de YouTube. También puedes usar calificaciones explícitas de los usuarios. Por último, si tienes una acción del usuario que usas como etiqueta, ver esa acción en el documento en un contexto diferente puede ser una gran función. Todas estas funciones te permiten incorporar contenido nuevo en el contexto. Ten en cuenta que esto no se trata de personalización: primero averigua si a alguien le gusta el contenido en este contexto y, luego, averigua a quién le gusta más o menos.

Regla n° 19: Usa funciones muy específicas cuando puedas.

Con toneladas de datos, es más fácil aprender millones de atributos simples que algunos atributos complejos. Los identificadores de los documentos que se recuperan y las consultas canonizadas no proporcionan mucha generalización, pero alinean tu clasificación con tus etiquetas en las consultas principales. Por lo tanto, no tengas miedo de los grupos de atributos en los que cada atributo 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 las características que se aplican a muy pocos ejemplos.

Regla n° 20: Combina y modifica las características existentes para crear nuevas de formas comprensibles para las personas.

Existen varias formas de combinar y modificar componentes. Los sistemas de aprendizaje automático, como TensorFlow, te permiten procesar tus datos de forma previa a través de transformaciones. Los dos enfoques más estándares son "discretizaciones" y "cruces".

La discretización consiste en tomar un atributo continuo y crear muchos atributos discretos a partir de él. Considera una característica continua, como la edad. Puedes crear una función que sea 1 cuando la edad sea inferior a 18 años, otra que sea 1 cuando la edad esté entre 18 y 35 años, etcétera. No analices demasiado los límites de estos histogramas: los cuantiles básicos te brindarán la mayor parte del impacto.

Los cruces combinan dos o más columnas de atributos. En la terminología de TensorFlow, una columna de atributos es un conjunto de atributos homogéneos (p.ej., {male, female}, {US, Canada, Mexico}, etcétera). Una combinación es una columna de atributos nueva con atributos en, por ejemplo, {male, female} × {US,Canada, Mexico}. Esta nueva columna contendrá el atributo (hombre, Canadá). Si usas TensorFlow y le indicas que cree esta combinación por ti, esta característica (hombre, Canadá) estará presente en los ejemplos que representen a hombres canadienses. Ten en cuenta que se necesitan grandes cantidades de datos para aprender modelos con cruces de tres, cuatro o más columnas de atributos básicos.

Es posible que las cruces que producen columnas de atributos muy grandes se ajusten en exceso. Por ejemplo, imagina que estás haciendo 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 cruz, pero terminarás con muchos atributos (consulta la regla n° 21).

Cuando se trabaja con texto, hay dos alternativas. El más drástico es un producto punto. Un producto punto en su forma más simple simplemente cuenta la cantidad de palabras en común entre la consulta y el documento. Luego, esta función se puede discretizar. Otro enfoque es una intersección: por lo tanto, tendremos un atributo que estará presente solo si la palabra “pony” está en el documento y en la búsqueda, y otro atributo que estará presente solo si la palabra “el” está en el documento y en la búsqueda.

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

Existen resultados fascinantes de la teoría del aprendizaje estadístico en relación con el nivel de complejidad adecuado para un modelo, pero esta regla es básicamente todo lo que necesitas saber. Tuve conversaciones en las que las personas dudaban de que se pueda aprender algo de mil ejemplos o de que alguna vez necesites más de un millón de ejemplos, porque se quedan atascadas en un método de aprendizaje determinado. La clave es escalar tu aprendizaje al tamaño de tus 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 la búsqueda, y tienes 1, 000 ejemplos etiquetados, debes usar un producto punto entre las características del documento y de la búsqueda, TF-IDF y media docena de otras características altamente diseñadas por humanos. 1,000 ejemplos, una docena de atributos.
  2. Si tienes un millón de ejemplos, interseca el documento y consulta las columnas de atributos, con la regularización y, posiblemente, la selección de atributos. Esto te dará millones de funciones, pero con la regularización, tendrás menos. Diez millones de ejemplos, quizás cien mil atributos.
  3. Si tienes miles de millones o cientos de miles de millones de ejemplos, puedes cruzar las columnas de atributos con tokens de documentos y consultas mediante la selección de atributos y la regularización. Tendrás mil millones de ejemplos y 10 millones de atributos. La teoría del aprendizaje estadístico rara vez proporciona límites estrictos, pero brinda una gran orientación para un punto de partida.

Al final, usa la regla n° 28 para decidir qué funciones usar.

Regla n.° 22: Limpia las funciones que ya no usas.

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

Ten en cuenta la cobertura cuando consideres qué funciones agregar o conservar. ¿Cuántos ejemplos abarca la función? Por ejemplo, si tienes algunas funciones de personalización, pero solo el 8% de tus usuarios las usa, no será muy eficaz.

Al mismo tiempo, algunas funciones pueden ser más útiles de lo que parecen. Por ejemplo, si tienes un atributo que abarca solo el 1% de los datos, pero el 90% de los ejemplos que tienen el 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 observar un modelo existente y mejorarlo. Esto es más un arte que una ciencia y, sin embargo, hay varios patrones contraproducentes que ayudan a evitar.

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

Esta es quizás la forma más fácil en que un equipo puede estancarse. Si bien el uso de prototipos en el equipo (alimentación de peces) y en la empresa (alimentación de perros) tiene muchos beneficios, los empleados deben verificar si el rendimiento es correcto. Si bien no se debe usar un cambio que sea obviamente malo, todo lo que se vea razonablemente cerca de la producción debe probarse más, ya sea pagando a personas no especializadas para que respondan preguntas en una plataforma de crowdsourcing o mediante un experimento en vivo en usuarios reales.

Existen dos motivos para ello. La primera es que estás demasiado cerca del código. Es posible que estés buscando un aspecto en particular de las publicaciones o que simplemente estés demasiado involucrado emocionalmente (p.ej., sesgo de confirmación). La segunda es que tu tiempo es demasiado valioso. Considera el costo de nueve ingenieros sentados en una reunión de una hora y piensa en cuántas etiquetas humanas contratadas compra en una plataforma de crowdsourcing.

Si realmente quieres obtener comentarios de los usuarios, usa metodologías de experiencia del usuario. Crea arquetipos de usuario (una descripción se encuentra en Sketching User Experiences de Bill Buxton) al principio de un proceso y realiza pruebas de usabilidad (una descripción se encuentra en Don't Make Me Think de Steve Krug) más adelante. Los arquetipos de usuario implican la creación de un usuario hipotético. Por ejemplo, si todo tu equipo es masculino, podría ser útil diseñar un arquetipo de usuario femenino de 35 años (completo con las características del usuario) y observar los resultados que genera en lugar de 10 resultados para hombres de entre 25 y 40 años. Invitar a personas reales para observar su reacción a tu sitio (de forma local o remota) en las pruebas de usabilidad también puede brindarte una perspectiva nueva.

Regla n° 24: Mide la diferencia entre los modelos.

Una de las mediciones más fáciles y, a veces, más útiles que puedes realizar antes de que ningún usuario vea 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 (ponderada por la posición de clasificación). Si la diferencia es muy pequeña, puedes saber sin ejecutar un experimento que habrá pocos cambios. Si la diferencia es muy grande, asegúrate de que el cambio sea bueno. Revisar las consultas en las que la diferencia simétrica es alta puede ayudarte a comprender de manera cualitativa cómo fue el cambio. Sin embargo, asegúrate de que el sistema sea estable. Asegúrate de que un modelo, cuando se compara consigo mismo, tenga una diferencia simétrica baja (idealmente, cero).

Regla n° 25: Cuando elijas modelos, el rendimiento utilitario supera el poder predictivo.

Tu modelo puede intentar predecir la tasa de clics. Sin embargo, al final, la pregunta clave es qué 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í. Si predices la probabilidad de que un documento sea spam y, luego, tienes un corte en lo que se bloquea, la precisión de lo que se permite es más importante. La mayoría de las veces, estos dos elementos deben coincidir: cuando no lo hacen, es probable que se trate de una ganancia pequeña. Por lo tanto, si hay algún cambio que mejore la pérdida de registro, pero degrade el rendimiento del sistema, busca otra función. Cuando esto comience a suceder con más frecuencia, es hora de revisar el objetivo de tu modelo.

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

Supongamos que ves un ejemplo de entrenamiento que el modelo “equivocó”. En una tarea de clasificación, este error podría ser un falso positivo o un falso negativo. En una tarea de clasificación, el error podría ser un par en el que un elemento positivo se clasificó más bajo que un elemento negativo. El punto más importante es que este es un ejemplo en el que el sistema de aprendizaje automático sabe que se equivocó y le gustaría corregirlo si tuviera la oportunidad. Si le das al modelo una función que le permita corregir el error, el modelo intentará usarla.

Por otro lado, si intentas crear una función basada en ejemplos que el sistema no considera errores, se ignorará. Por ejemplo, supongamos que en la Búsqueda de apps de Play, alguien busca "juegos gratuitos". Supongamos que uno de los resultados principales es una app de broma menos relevante. Por lo tanto, creas una función para "apps de broma". Sin embargo, si deseas maximizar la cantidad de instalaciones y las personas instalan una app falsa cuando buscan juegos gratuitos, la función de "apps falsas" no tendrá el efecto que deseas.

Una vez que tengas ejemplos en los que el modelo se equivocó, busca tendencias que se encuentren fuera de tu conjunto de atributos actual. Por ejemplo, si parece que el sistema está quitando la clasificación de las publicaciones más largas, agrega la longitud de la publicación. No seas demasiado específico sobre las funciones que agregues. Si vas a agregar la longitud de la publicación, no intentes adivinar qué significa “largo”, solo agrega una docena de atributos y deja que el modelo determine qué hacer con ellos (consulta la regla n° 21). Esa es la forma más fácil de obtener lo que deseas.

Regla n° 27: Intenta cuantificar el comportamiento no deseado observado.

Algunos miembros de tu equipo comenzarán a frustrarse con las propiedades del sistema que no les gustan y que no captura la función de pérdida existente. En este punto, debe hacer lo que sea necesario para convertir sus quejas en números sólidos. Por ejemplo, si creen que se muestran demasiadas "apps de broma" en la Búsqueda de Play, podrían pedirles a los evaluadores humanos que las identifiquen. (En este caso, puedes usar datos etiquetados por humanos, ya que una fracción relativamente pequeña de las consultas representa una gran fracción del tráfico). Si tus problemas son medibles, puedes comenzar a usarlos como funciones, objetivos o métricas. La regla general es "primero mide, luego optimiza".

Regla n° 28: Ten en cuenta que un 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 doc de cada consulta. Descubres que su comportamiento es casi idéntico al de tu sistema actual en las comparaciones y las pruebas A/B, por lo que, debido a su simplicidad, lo lanzas. Sin embargo, notas que no se muestran apps nuevas. ¿Por qué? Como tu sistema solo muestra un documento en función de su propio historial con esa consulta, no hay forma de saber que se debe mostrar un documento nuevo.

La única manera de comprender cómo funcionaría un sistema de este tipo a largo plazo es entrenarlo solo con los datos adquiridos cuando el modelo estaba activo. Esto es muy difícil.

Sesgo entre el entrenamiento y la entrega

La desviación entre el entrenamiento y la entrega es una diferencia entre el rendimiento durante el entrenamiento y el rendimiento durante la entrega. Este sesgo puede deberse a lo siguiente:

  • Una discrepancia entre la manera en que manejas los datos en las canalizaciones de entrenamiento y las de entrega.
  • Un cambio en los datos entre el momento de entrenamiento y el momento de la entrega.
  • Un ciclo de retroalimentación entre tu modelo y tu algoritmo.

En Google, observamos sistemas de aprendizaje automático de producción con sesgos de entrenamiento y entrega que afectan negativamente el rendimiento. La mejor solución es supervisarlo de forma explícita para que los cambios en el sistema y los datos no introduzcan sesgos sin que se noten.

Regla n.° 29: La mejor manera de asegurarte de entrenar como entregas es guardar el conjunto de atributos utilizados en el momento de la entrega y, luego, canalizarlos a un registro para usarlos en el momento del entrenamiento.

Incluso si no puedes hacerlo para todos los ejemplos, hazlo para una pequeña fracción, de modo que puedas verificar la coherencia entre la publicación y el entrenamiento (consulta la regla n° 37). A veces, los resultados sorprendieron a los equipos que realizaron esta medición en Google. La página principal de YouTube cambió a las funciones de registro en el tiempo de publicación con mejoras significativas de calidad y una reducción en la complejidad del código, y muchos equipos están cambiando su infraestructura en este momento.

Regla n° 30: No descartes arbitrariamente los datos muestreados con ponderación de importancia.

Cuando tienes demasiados datos, es tentador tomar los archivos del 1 al 12 y olvidarse de los del 13 al 99. Esto es un error. Aunque se pueden descartar los datos que nunca se le mostraron al usuario, la ponderación de importancia es mejor para el resto. La ponderación de importancia significa que, si decides que vas a muestrear el ejemplo X con una probabilidad del 30%, debes darle un peso de 10/3. Con la ponderación de importancia, se mantienen todas las propiedades de calibración que se analizaron en la regla n° 14.

Regla n° 31: Ten en cuenta que, si unes datos de una tabla en el momento del entrenamiento y la entrega, es posible que los datos de la tabla cambien.

Supongamos que unes los IDs de los documentos con una tabla que contiene atributos para esos documentos (como la cantidad de comentarios o clics). Entre el tiempo de entrenamiento y el de publicación, es posible que cambien los atributos de 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 las funciones en el momento de la publicación (consulta la regla n° 32). Si la tabla solo cambia lentamente, también 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 el problema por completo.

Regla n° 32: Reutiliza el código entre tu canalización de entrenamiento y tu canalización de publicación siempre que sea posible.

El procesamiento por lotes es diferente del procesamiento en línea. En el procesamiento en línea, debes controlar cada solicitud a medida que llega (p.ej., debes realizar una búsqueda independiente para cada consulta), mientras que en el procesamiento por lotes, puedes combinar tareas (p.ej., realizar una unión). En el momento de la publicación, realizas el procesamiento en línea, mientras que el entrenamiento es una tarea de procesamiento por lotes. Sin embargo, hay algunas acciones que puedes hacer para volver a usar el código. Por ejemplo, puedes crear un objeto particular para tu sistema en el que el resultado de cualquier consulta o unión se pueda almacenar de una manera muy legible por humanos y los errores se puedan probar fácilmente. Luego, una vez que hayas recopilado toda la información, durante la publicación o el entrenamiento, ejecutas un método común para establecer un puente entre el objeto legible por humanos que es específico de tu sistema y cualquier formato que espere el sistema de aprendizaje automático. Esto elimina una fuente de sesgo de entrenamiento y entrega. Como resultado, intenta no usar dos lenguajes de programación diferentes entre el entrenamiento y la publicación. Esa decisión hará que sea casi imposible que compartas código.

Regla n° 33: Si generas un modelo basado en los datos hasta el 5 de enero, pruébalo con los datos del 6 de enero en adelante.

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 generas un modelo basado en los datos hasta el 5 de enero, prueba el modelo en los datos del 6 de enero. Es probable 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 puedas predecir la tasa de clics o el porcentaje de conversiones promedio, pero el área bajo la curva, que representa la probabilidad de que el ejemplo positivo tenga una puntuación más alta que un ejemplo negativo, debería ser bastante cercana.

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

En una tarea de filtrado, los ejemplos marcados como negativos no se muestran al usuario. Supongamos que tienes un filtro que bloquea el 75% de los ejemplos negativos durante la publicación. Es posible que te sientas tentado a 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 tu filtro dejó pasar, te recomendamos que aprendas de esa experiencia.

Sin embargo, este enfoque introduce un sesgo de muestreo. Puedes recopilar datos más limpios si, en su lugar, durante la publicación, etiquetas el 1% de todo el tráfico como "retenido" y envías todos los ejemplos retenidos al usuario. Ahora, tu filtro bloquea al menos el 74% de los ejemplos negativos. Estos ejemplos reservados pueden convertirse 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 la publicación, puedes tomar 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° 35: Ten cuidado con la distorsión inherente en los problemas de clasificación.

Cuando cambias tu algoritmo de clasificación de forma radical para que aparezcan resultados diferentes, cambias de manera efectiva los datos que tu algoritmo verá en el futuro. Aparecerá este tipo de sesgo, y debes diseñar tu modelo en función de él. Existen varios enfoques diferentes. Estos enfoques son todas las formas de favorecer los datos que tu modelo ya vio.

  1. Tener una regularización más alta en las funciones que abarcan más consultas en comparación con aquellas que están activadas solo para una consulta De esta manera, el modelo favorecerá las funciones específicas de una o varias consultas en lugar de las funciones que se generalizan a todas las consultas. Este enfoque puede ayudar a evitar que los resultados muy populares se filtren en consultas irrelevantes. Ten en cuenta que esto es lo opuesto al consejo más convencional de tener más regularización en las columnas de atributos con más valores únicos.
  2. Solo permite que los componentes tengan pesos positivos. Por lo tanto, cualquier atributo bueno será mejor que un atributo que sea "desconocido".
  3. No tienen funciones exclusivas para documentos. Esta es una versión extrema del punto 1. Por ejemplo, incluso si una app determinada es una descarga popular, independientemente de la búsqueda, no querrás mostrarla en todas partes. No tener funciones solo para documentos mantiene la simplicidad. El motivo por el que no quieres mostrar una app popular específica en todas partes tiene que ver con la importancia de que se pueda acceder a todas las apps deseadas. Por ejemplo, si alguien busca "app para observar aves", es posible que descargue "Angry Birds", pero ese no era su objetivo. Mostrar una app de este tipo podría mejorar la tasa de descargas, pero, en última instancia, no satisfaría las necesidades del usuario.

Regla n° 36: Evita los bucles de retroalimentación con componentes posicionales.

La posición del contenido afecta de manera significativa las probabilidades de que el usuario interactúe con él. Si colocas una app en la primera posición, se hará clic en ella con más frecuencia, y te convencerás de que es más probable que se haga clic en ella. Una forma de abordar 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, el atributo “1ª posición” en gran medida. Por lo tanto, tu modelo otorga menos importancia a otros factores para los ejemplos con "1st­position=true". Luego, en la publicación, no le asignas el atributo de posición a ninguna instancia, o les asignas a todas el mismo atributo predeterminado, porque estás asignando puntuaciones a los candidatos antes de decidir el orden en el que se mostrarán.

Ten en cuenta que es importante mantener las características posicionales un poco separadas del resto del modelo debido a esta asimetría entre el entrenamiento y las pruebas. 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 las funciones posicionales con ninguna función de documento.

Regla n° 37: Mide el sesgo entre el entrenamiento y la entrega.

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

  • La diferencia entre el rendimiento de los datos de entrenamiento y los datos de retención. En general, esto siempre existirá y no siempre es malo.
  • La diferencia entre el rendimiento de los datos de retención y los datos del "día siguiente" Una vez más, esto siempre existirá. Debes ajustar la regularización para maximizar el rendimiento del día siguiente. Sin embargo, las grandes disminuciones en el rendimiento entre los datos del conjunto de validación y los del día siguiente pueden indicar que algunas funciones son de uso inmediato y, posiblemente, degradan el rendimiento del modelo.
  • Es la diferencia entre el rendimiento de los datos del "día siguiente" y los datos en vivo. Si aplicas un modelo a un ejemplo en los datos de entrenamiento y al mismo ejemplo en la entrega, deberías obtener exactamente el mismo resultado (consulta Regla n° 5 ). Por lo tanto, una discrepancia aquí probablemente indique un error de ingeniería.

Fase III de la AA: crecimiento lento, perfeccionamiento de la optimización y modelos complejos

Habrá ciertos indicadores de que la segunda fase está llegando a su fin. En primer lugar, tus 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 pone interesante. Como los beneficios son más difíciles de lograr, el aprendizaje automático debe ser más sofisticado. Una advertencia: esta sección tiene más reglas ideales que las secciones anteriores. Hemos visto a muchos equipos pasar por los buenos momentos del aprendizaje automático de las fases I y II. Una vez que se alcanza la Fase III, los equipos deben encontrar su propio camino.

Regla n° 38: No pierdas tiempo en funciones nuevas si los objetivos no alineados se convirtieron en el problema.

A medida que tus mediciones se estabilicen, tu equipo comenzará a analizar los problemas que están fuera del alcance de los objetivos de tu sistema de aprendizaje automático actual. Como se mencionó antes, si el objetivo algorítmico existente no abarca los objetivos del producto, debes cambiar tu objetivo o los objetivos del producto. Por ejemplo, puedes optimizar los clics, los Me gusta o las descargas, pero tomar decisiones de lanzamiento en función, en parte, de calificadores humanos.

Regla n° 39: Las decisiones de lanzamiento son un proxy de los objetivos a largo plazo del producto.

Alice tiene una idea para reducir la pérdida logística de predecir las instalaciones. Agrega una función. La pérdida logística disminuye. Cuando realiza un experimento en vivo, ve que aumenta la tasa de instalación. Sin embargo, cuando asiste a una reunión de revisión del lanzamiento, alguien señala que la cantidad de usuarios activos por día disminuye un 5%. El equipo decide no lanzar el modelo. Alice se siente decepcionada, pero ahora se da cuenta de que las decisiones de lanzamiento dependen de varios criterios, de los cuales solo algunos se pueden optimizar directamente con el AA.

La verdad es que el mundo real no es Dungeons and Dragons: no hay “puntos de golpe” que identifiquen el estado de tu producto. El equipo debe usar las estadísticas que recopila para intentar predecir de manera eficaz qué tan bueno será el sistema en el futuro. Debe preocuparse por la participación, los usuarios activos por 1 día (DAU), los DAU durante 30 días, los ingresos y el retorno de la inversión del anunciante. Estas métricas que se pueden medir en las pruebas A/B en sí son solo un proxy para objetivos a más largo plazo: satisfacer a los usuarios, aumentar la cantidad de usuarios, satisfacer a los socios y obtener ganancias, que incluso podrían considerarse proxies para tener un producto útil y de alta calidad, y una empresa próspera dentro de cinco años.

Las únicas decisiones de lanzamiento fáciles son cuando todas las métricas mejoran (o al menos no empeoran). Si el equipo tiene la opción de elegir entre un algoritmo de aprendizaje automático sofisticado y una heurística simple, y la heurística simple funciona mejor en todas estas métricas, debe elegir la heurística. Además, no hay una clasificación explícita de todos los valores de métrica posibles. Específicamente, considera las siguientes dos situaciones:

Experimento Usuarios activos por día Ingresos por 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, es poco probable que el equipo cambie a A. Esto parece estar en conflicto con el comportamiento racional. Sin embargo, las predicciones de cambio de métricas pueden o no ser exitosas, por lo que existe un gran riesgo en cualquier cambio. Cada métrica abarca algún riesgo que preocupa al equipo.

Además, ninguna métrica abarca la principal preocupación 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 tipo de entorno. Un Ingeniero que crea funciones nuevas puede obtener una cantidad constante de lanzamientos en un entorno de este tipo. Hay un tipo de aprendizaje automático, el aprendizaje multiobjetivo, que comienza a abordar este problema. Por ejemplo, se puede formular un problema de satisfacción de restricciones que tenga límites más bajos en cada métrica y optimice alguna combinación lineal de métricas. Sin embargo, incluso así, 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 averiguar por qué un usuario visita tu sitio. La forma de predecir el éxito futuro de un sitio en su totalidad es completamente de IA: tan difícil como la visión artificial o el procesamiento de lenguaje natural.

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

Los modelos unificados que toman atributos sin procesar y clasifican directamente el contenido son los 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 conjunto que solo tome la entrada de otros modelos o un modelo base que tome muchas características, pero no ambas. Si tienes modelos sobre otros modelos que se entrenan por separado, combinarlos puede generar un comportamiento incorrecto.

Usa un modelo simple para el ensamble que tome solo el resultado de tus modelos “base” como entradas. También quieres aplicar propiedades en estos modelos de conjunto. Por ejemplo, un aumento en la puntuación que produce un modelo base no debería disminuir la puntuación del conjunto. Además, es mejor que los modelos entrantes se puedan interpretar semánticamente (por ejemplo, calibrados) para que los cambios de los modelos subyacentes no confundan al modelo de conjunto. Además, exige que un aumento en la probabilidad prevista de un clasificador subyacente no disminuya la probabilidad prevista del conjunto.

Regla n° 41: Cuando el rendimiento se estabilice, busca fuentes de información cualitativamente nuevas para agregar en lugar de definir mejor los indicadores existentes.

Agregaste información demográfica sobre el usuario. Agregaste información sobre las palabras del documento. Realizaste la exploración de plantillas y ajustaste la regularización. No has visto un lanzamiento con más de un 1% de mejora en tus métricas clave en algunos trimestres. ¿Qué sigue?

Es hora de comenzar a compilar la infraestructura para funciones radicalmente diferentes, como el historial de documentos a los que accedió este usuario en el último día, semana o año, o los datos de una propiedad diferente. Usa entidades de wikidata o algo interno de tu empresa (como el gráfico de conocimiento de Google). Usa el aprendizaje profundo. Empieza 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 sopesar el beneficio de agregar funciones nuevas con el costo de una mayor complejidad.

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

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

El problema es que lo común suele ser difícil de superar.

Ten en cuenta que, si tu sistema mide los clics, el tiempo dedicado, las reproducciones, los +1, los reenvíos, etcétera, estás midiendo la popularidad del contenido. A veces, los equipos intentan aprender un modelo personal con diversidad. Para personalizar, agregan funciones que permitirían que el sistema personalice (algunas funciones que representan el interés del usuario) o diversifique (funciones que indican si este documento tiene alguna función en común con otros documentos que se muestran, como el autor o el contenido) y descubren que esas funciones 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 señaló en la regla anterior, puedes realizar el procesamiento posterior para aumentar la diversidad o la relevancia. Si observas que aumentan los objetivos a largo plazo, puedes afirmar que la diversidad o la relevancia son valiosas, además de la popularidad. Luego, puedes seguir usando el procesamiento posterior o modificar directamente el objetivo en función de la diversidad o la relevancia.

Regla n° 43: Tus amigos suelen ser los mismos en diferentes productos. Tus intereses suelen no serlo.

Los equipos de Google obtuvieron mucho éxito cuando tomaron un modelo que predice la proximidad de una conexión en un producto y lo hicieron funcionar bien en otro. Tus amigos son como son. Por otro lado, he visto a varios equipos luchar con las funciones de personalización en diferentes divisiones de productos. Sí, parece que debería funcionar. Por ahora, no parece que sea así. En ocasiones, funciona usar datos sin procesar de una propiedad para predecir el comportamiento en otra. Además, ten en cuenta que incluso saber que un usuario tiene un historial en otra propiedad puede ser útil. Por ejemplo, la presencia de actividad del usuario en dos productos puede ser una indicación en sí misma.

Hay muchos documentos sobre el aprendizaje automático en Google y también de forma externa.

Agradecimientos

Gracias 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, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira y Hrishikesh Aradhye por las correcciones, sugerencias y ejemplos útiles para este documento. También, gracias a Kristen Lefevre, Suddha Basu y Chris Berg, que ayudaron con una versión anterior. Cualquier error, omisión o (¡uf!) opinión impopular son de mi responsabilidad.

Apéndice

En este documento, se incluyen varias referencias a los productos de Google. Para proporcionar más contexto, a continuación, te envío una breve descripción de los ejemplos más comunes.

Descripción general de YouTube

YouTube es un servicio de transmisión de video. Los equipos de Mirar a continuación y de la página principal de YouTube usan modelos de IA para clasificar las recomendaciones de videos. Mirar a continuación recomienda video para mirar después del que se está reproduciendo, mientras que la página principal recomienda video a los usuarios que la exploran.

Descripción general de Google Play

Google Play tiene muchos modelos que resuelven una variedad de problemas. La Búsqueda de Play, las Recomendaciones personalizadas de la página principal de Play y las apps de "Los usuarios también instalaron" usan el aprendizaje automático.

Descripción general de Google Plus

Google Plus usaba el aprendizaje automático en una variedad de situaciones: clasificar las publicaciones en el "flujo" de publicaciones que veía el usuario, clasificar las publicaciones de "Novedades" (publicaciones que son muy populares en el momento), clasificar a las personas que conoces, etcétera. Google Plus cerró todas las cuentas personales en 2019 y se reemplazó por Google Currents para las cuentas de empresa el 6 de julio de 2020.