Reglas del aprendizaje automático:

Prácticas recomendadas para la ingeniería de AA

Martín Zinkevich

El objetivo de este documento es ayudar a las personas con conocimientos básicos sobre aprendizaje automático a aprovechar las prácticas recomendadas de Google en materia de aprendizaje automático. Presenta un estilo para aprendizaje automático, similar a la Guía de estilo de Google C++ y otras guías populares para programación práctica. Si tomaste una clase sobre aprendizaje automático, o creaste un modelo de aprendizaje automático o trabajaste con uno, tienes la información necesaria para leer este documento.

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

Terminología

Los siguientes términos se mencionarán de forma reiterada en nuestro debate sobre un aprendizaje automático eficaz:

  • Instancia: 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: Una respuesta a una 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 de una página web podría ser "sobre gatos".
  • Atributo: Es una propiedad de una instancia utilizada en una tarea de predicción. Por ejemplo, una página web podría 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 posible que vivan los usuarios. Un ejemplo puede tener uno o más atributos 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 basado en ejemplos y, luego, lo usas para hacer predicciones.
  • Métrica: El número que importa. Se puede optimizar 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: Es el porcentaje de visitantes a una página web que hacen clic en el vínculo de un anuncio.

Descripción general

Para crear excelentes productos:

Aborda el aprendizaje automático como un gran ingeniero, no como un gran experto en aprendizaje automático que no seas.

La mayoría de los problemas a los que te enfrentarás son, de hecho, 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 atributos 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 características de sentido común de manera sencilla.
  4. Asegúrate de que tu canalización se mantenga sólida.

Este enfoque funcionará bien durante un largo período. Modifica este enfoque solo cuando no haya más trucos simples para llegar más lejos. Si sumas complejidad, se ralentizan las versiones futuras.

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

Este documento está organizado 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 trata sobre 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 heuristics básica no tenga un buen rendimiento. Si crees que el aprendizaje automático te dará un aumento 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 editores que enviaron spam anteriormente. 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 indispensable para tu producto, no lo uses hasta que tengas datos.

Regla n.o 2: En primer lugar, diseña métricas e impleméntalas.

Antes de formalizar lo que hará tu 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 comienzo.
  2. Si crees que algo puede ser un problema en el futuro, es mejor obtener los datos históricos ahora.
  3. Si diseñas el sistema con la instrumentación de métricas en mente, las cosas irán mejor en el futuro. En particular, si no deseas realizar búsquedas globales de strings en registros para instrumentar las métricas.
  4. Notarás qué cosas cambian y qué permanecen iguales. Por ejemplo, supongamos que quieres optimizar directamente los usuarios activos de 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 afectan de forma notoria esta métrica.

El equipo de Google Plus mide las expansiones por lectura, cantidad de veces que se comparte una publicación, más una por cada lectura, comentarios por cada comentario/lectura, comentarios por usuario, cantidad de veces que se comparte por usuario, etc. Esto se usa para calcular el rendimiento de una publicación al momento de la publicación. Además, ten en cuenta que es importante un framework de experimento, en el que puedes agrupar usuarios en buckets y agregar estadísticas por experimento. Consulta la regla n.o 12.

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

Regla n.o 3: Elige aprendizaje automático antes que una heurística compleja.

Una heurística simple puede hacer que tu producto salga al mercado. Una heurística compleja es insostenible. Una vez que tengas los datos y una idea básica de lo que estás tratando de lograr, pasa al aprendizaje automático. Como en la mayoría de las tareas de ingeniería de software, querrás actualizar tu enfoque de forma constante, ya sea un modelo heurístico o 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.o 16).

Fase I del AA: Tu primera canalización

Enfócate en la infraestructura de tu sistema para la primera canalización. Si bien es divertido pensar en todo el aprendizaje automático imaginativo que harás, será difícil averiguar qué está sucediendo si no confías primero en tu canalización.

Regla n.o 4: Procura que el primer modelo se mantenga simple y acierta con la infraestructura.

El primer modelo proporciona el mayor impulso para tu producto, por lo que no necesita ser elaborado. 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 elegante sistema de aprendizaje automático, tienes que determinar lo siguiente:

  • Cómo obtener ejemplos para tu algoritmo de aprendizaje
  • Un primer repaso sobre lo que significan “bueno” y “malo” para tu sistema.
  • Cómo integrar tu modelo en la aplicación Puedes aplicar el modelo en vivo o procesarlo previamente con ejemplos sin conexión y almacenar los resultados en una tabla. Por ejemplo, es posible que desees clasificar previamente páginas web y almacenar los resultados en una tabla, pero que quieras clasificar los mensajes de chat en vivo.

Si eliges funciones simples, es más fácil garantizar lo siguiente:

  • Que los atributos se comuniquen con tu algoritmo de aprendizaje correctamente.
  • El modelo aprende pesos razonables.
  • Que los atributos se comuniquen con tu modelo en el servidor correctamente.

Una vez que tengas un sistema que realice estas tres tareas de manera confiable, habrás completado la mayor parte del trabajo. Un modelo simple te proporciona métricas y un comportamiento de modelo de referencia que puedes usar para probar modelos más complejos. Algunos equipos apuntan a un primer lanzamiento "neutral", es decir, uno que no da prioridad explícitamente a las ganancias del aprendizaje automático para evitar distraerse.

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

Asegúrate de que se pueda probar la infraestructura 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 obtener datos para el 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, verifica 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 del entorno de entrenamiento muestre el mismo resultado que el modelo del entorno de publicación (consulta la regla n.o 37).

El aprendizaje automático tiene un elemento de imprevisibilidad, así que asegúrate de probar el código para crear ejemplos en el entrenamiento y la entrega, y de que puedas cargar y usar un modelo fijo durante la entrega. Además, es importante comprender tus 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 copies canalizaciones.

A menudo, para crear una canalización, copiamos una existente (es decir, la programación a ciegas) y la canalización anterior pierde datos que necesitamos en la canalización nueva. Por ejemplo, la canalización para la sección Lo más interesante de Google+ pierde las publicaciones anteriores (porque intenta clasificar las publicaciones nuevas). Esta canalización se copió para usarla en las Novedades de Google+, donde las publicaciones anteriores aún son significativas, pero la canalización sigue descartando publicaciones antiguas. Otro patrón común es solo registrar 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. Ocurrió un problema similar en Play. Mientras se trabajaba en la página de inicio de Play Apps, 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 de dónde provino cada ejemplo.

Regla n.o 7: Convierte la heurística en atributos o contrólalos externamente.

Por lo general, los problemas que el aprendizaje automático intenta resolver no son completamente nuevos. Ya existe un sistema de clasificación, clasificación o el problema que intentes resolver. Esto significa que hay un montón de reglas y heurísticas. Estas mismas heurísticas pueden ser de gran ayuda cuando se modifican con el aprendizaje automático. Debes recolectar toda la información que tengan tus heurísticas por dos motivos. Primero, la transición a un sistema de aprendizaje automático será más fluida. En segundo lugar, generalmente esas reglas contienen mucha de la intuición sobre el sistema que no quieres desechar. Existen cuatro maneras de usar una heurística existente:

  • Procesamiento previo 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á incluido en la lista negra, no intentes volver a aprender qué significa "incluido en la lista negra". Bloquea el mensaje. Este enfoque tiene más sentido en tareas de clasificación binaria.
  • Crea un atributo. Crear directamente un atributo a partir de la heurística es genial. Por ejemplo, si usas una heurística para calcular la puntuación de relevancia de un resultado de 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, convertir el valor en uno de un conjunto finito de valores discretos o combinarlo con otros atributos), pero comienza usando el valor sin procesar producido por la heurística.
  • Extrae 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 contenido de calidad, la solución puede ser multiplicar la etiqueta por la cantidad promedio de estrellas que recibió la app. Esta opción permite mucha libertad. Consulta la sección "Tu primer objetivo".

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

Supervisión

En general, adopta un buen estado de alerta, como hacer que las alertas sean prácticas y contar con una página de panel.

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

¿Cuánto se degrada el rendimiento si el modelo tiene un día de antigüedad? ¿Hace una semana? ¿Un cuarto de antigüedad? Esta información puede ayudarte a comprender las prioridades de tu supervisión. Si pierdes una calidad significativa del producto 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 entrega de anuncios tienen que manejar anuncios nuevos todos los días 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 Lo más interesante en Google+ no tienen un identificador de publicaciones, por lo que pueden exportar estos modelos con poca frecuencia. 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 tu 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 del usuario.

Realiza las verificaciones de estado justo antes de exportar el modelo. Específicamente, asegúrate de que el rendimiento del modelo sea razonable en los datos existentes. Si tienes problemas persistentes con los datos, no exportes el modelo. Muchos equipos que implementan continuamente modelos verifican el área bajo la curva ROC (o AUC) antes de la exportación. Los problemas sobre modelos que no se exportaron requieren 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: Presta atención a los fallos silenciosos.

Este es un problema que ocurre con más frecuencia en los sistemas de aprendizaje automático que en otros tipos de sistemas. Supongamos que una tabla particular que se une ya no se actualiza. El sistema de aprendizaje automático se ajustará y el comportamiento seguirá siendo razonablemente bueno, con una disminución gradual. A veces, encuentras tablas con meses de atraso, y una simple actualización mejora el rendimiento más que cualquier otro lanzamiento ese trimestre. La cobertura de un atributo puede cambiar debido a los cambios de 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 tenía una tabla que estaba inactiva durante 6 meses, y actualizar solo la tabla generó un aumento del 2% en la tasa de instalaciones. Si ocasionalmente realizas un seguimiento de las estadísticas de los datos y también inspeccionas los datos de forma manual, puedes reducir este tipo de fallas.

Regla n.o 11: Asigna propietarios y documentación para 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 la persona que entiende una columna de atributos se va, asegúrate de que alguien tenga esa información. Aunque muchas columnas de atributos tienen nombres descriptivos, se recomienda 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 interesan muchas 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. Hago una distinción entre objetivos y métricas: una métrica es cualquier número que informa el sistema, que puede ser importante o no. Consulta también la regla n.o 2.

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

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

Por lo tanto, hazlo de forma simple y no pienses demasiado en equilibrar las diferentes métricas cuando puedas aumentar fácilmente todas las métricas. Sin embargo, no lleves demasiado lejos esta regla: no confundas tu objetivo con el estado general del sistema (consulta la regla n.o 39). Además, si aumentas la métrica optimizada directamente, pero decides no realizar el lanzamiento, es posible que debas revisar los objetivos.

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

Por lo general, no se sabe cuál es el verdadero objetivo. Crees que sí, pero luego, cuando observas los datos y el análisis en paralelo de tu sistema antiguo y el nuevo sistema de AA, te das cuenta de que deseas ajustar el objetivo. Además, los miembros del equipo no suelen ponerse de acuerdo sobre el verdadero objetivo. El objetivo del AA debe ser algo que sea fácil de medir y que represente al “verdadero” objetivo. De hecho, a menudo no existe un "verdadero" objetivo (consulta la regla n.o 39). Por lo tanto, entrena en el objetivo de AA simple y considera tener una “capa de política” 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 el comportamiento de un usuario que se observa directamente y se atribuye a una acción del sistema:

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

Al principio, evita los efectos indirectos del modelado:

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

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 hacer que el aprendizaje automático adivine lo siguiente:

  • ¿El usuario está satisfecho con el 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 son importantes, pero también increíblemente difíciles de medir. En cambio, usa proxies: si el usuario está feliz, permanecerá en el sitio por más tiempo. Si el usuario está satisfecho, volverá a visitar la tienda mañana. En cuanto al bienestar y el estado de la empresa, se requiere el criterio humano para conectar cualquier objetivo de aprendizaje automático con la naturaleza del producto que vendes y tu plan de negocios.

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 motivadas por un modelo probabilístico. Cada predicción se interpreta como una probabilidad o un valor esperado. Esto hace que sean más fáciles de depurar que los modelos que usan objetivos (pérdida cero uno, 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 mediante 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 datos en los que la expectativa promedio prevista es igual a la etiqueta promedio (calibrado con 1 momento o simplemente calibrado). Esto es cierto siempre que no tengas una regularización, que el algoritmo haya convergido y que sea aproximadamente cierto en general. Si tienes un atributo que es 1 o 0 para cada ejemplo, entonces el conjunto de 3 ejemplos donde ese atributo es 1 se calibra. Además, si tienes un atributo que es 1 para cada ejemplo, entonces 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 según el valor esperado decreciente (es decir, la probabilidad de clic/descarga, 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 bello, pero el filtrado de spam es una guerra. Los indicadores que utilices para determinar las publicaciones de alta calidad serán evidentes para quienes usen tu sistema, y modificará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 descartar al estudiante de la clasificación de calidad por clasificar muy alto el spam. Del mismo modo, el contenido "subido de tono" debe tratarse por separado de la clasificación de calidad. El filtro de spam es otra historia. Es esperable que los atributos que debes generar cambien constantemente. Con frecuencia, habrá reglas obvias que pondrás en el sistema (si una publicación tiene más de tres votos de spam, no la recuperes, etcétera). Los modelos aprendidos se deben actualizar diariamente o más rápido. La reputación del creador del contenido tendrá un papel importante.

En algún nivel, el resultado de estos dos sistemas tendrá que integrarse. Recuerda que el filtrado de spam en los resultados de la búsqueda probablemente debería ser más agresivo que el de los mensajes de correo electrónico. Además, es una práctica estándar quitar el spam de los datos de entrenamiento para el clasificador de calidad.

Fase II de AA: Ingeniería de atributos

En la primera fase del ciclo de vida de un sistema de aprendizaje automático, los problemas importantes son colocar los datos de entrenamiento en el sistema de aprendizaje, instrumentar cualquier métrica de interés y crear una infraestructura de entrega. Una vez que tengas un sistema operativo de extremo a extremo con pruebas de unidades y sistema instrumentadas, comienza la Fase II.

En la segunda fase, hay muchos beneficios inmediatos. Hay una variedad de atributos obvios que se pueden incluir en el sistema. Por lo tanto, la segunda fase del aprendizaje automático implica incorporar la mayor cantidad posible de atributos y combinarlos de forma intuitiva. 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 reunir todos los datos que necesitas para crear un sistema de aprendizaje realmente increíble.

Regla n.o 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 o, incluso, que alguna vez dejarás de lanzar modelos. Por lo tanto, considera si la complejidad que agregas con este lanzamiento ralentizará los lanzamientos futuros. Muchos equipos lanzaron un modelo por trimestre o más durante años. Existen tres razones básicas para lanzar modelos nuevos:

  • Tienes nuevas funciones.
  • Estás ajustando la regularización y combinando atributos antiguos de formas nuevas.
  • Deseas ajustar el objetivo.

En cualquier caso, puede ser bueno darle un poco de amor a un modelo: analizar los datos que se ingresan en el ejemplo puede ayudarte a encontrar indicadores nuevos, así como indicadores antiguos rotos. Por lo tanto, mientras creas 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 si es posible ejecutar dos o tres copias en paralelo. Por último, no te preocupes si la función 16 de 35 aparece en esta versión de la canalización. Las incluirá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 controvertido, pero evita muchos problemas. Primero, describamos qué es un atributo aprendido. Un atributo aprendido es un atributo generado por un sistema externo (como un sistema de agrupamiento en clústeres no supervisado) o el propio algoritmo (p.ej., mediante un modelo factorizado o el aprendizaje profundo). Ambas opciones 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 ese sistema tiene su propio objetivo. Es posible que el objetivo del sistema externo no esté relacionado con tu objetivo actual. Si tomas una instantánea del sistema externo, es posible que esté desactualizada. Si actualizas los atributos desde el sistema externo, es posible que los significados cambien. Si usas un sistema externo para proporcionar un atributo, ten en cuenta que este enfoque requiere mucho cuidado.

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 encuentra en cada iteración puede ser diferente. Esta variación hace que sea difícil juzgar si el impacto de un cambio en tu sistema es significativo o aleatorio. Si creas un modelo sin atributos profundos, puedes obtener un modelo de referencia de rendimiento excelente. Una vez que se alcanza este punto de referencia, puedes probar enfoques más esotéricos.

Regla n.o 18: Explora con características de contenido que generalicen a través de contextos.

A menudo, un sistema de aprendizaje automático es solo una pequeña parte de un panorama mucho más amplio. Por ejemplo, si te imaginas una publicación que se podría utilizar en "Lo más interesante", muchas personas harán más uno, la compartirán o la comentarán antes de que aparezca en "Lo más interesante". Si proporcionas esas estadísticas al alumno, este puede promocionar nuevas publicaciones para las que no tiene datos en el contexto que está optimizando. La sección Ver a continuación de YouTube podría usar la cantidad de reproducciones, o reproducciones en compañía (recuentos de la cantidad de veces que se miró un video después de otro) en la búsqueda de YouTube. También puedes usar clasificaciones de usuarios explícitas. Por último, si usas una acción del usuario como etiqueta, ver esa acción en el documento en un contexto diferente puede ser una excelente función. Todas estas funciones te permiten aportar contenido nuevo al contexto. Ten en cuenta que esto no se trata de personalización: primero descubre si a alguien le gusta el contenido en este contexto y, luego, descubre a quién le gusta más o menos.

Regla n.o 19: Usa atributos muy específicos siempre que puedas.

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 proporcionan mucha generalización, pero alinean tu clasificación con las etiquetas en las consultas principales. Por lo tanto, no te preocupes 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 supera el 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 de una forma comprensible para los humanos.

Hay 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 estándar 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 que 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 te darán el mayor impacto posible.

Las combinaciones 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., {masculino, femenino}, {EE.UU., Canadá, México}, etcétera). Una combinación es una columna de atributos nueva con atributos en, por ejemplo, {masculino, femenino} × {EE.UU., Canadá, México}. Esta nueva columna 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 hombres canadienses. 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 sobreajuste. 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. Si lo combinas con una combinación, terminarás con muchos atributos (consulta la regla n.o 21).

Cuando se trabaja con texto, existen dos alternativas. La más rigurosa es un producto escalar. En su forma más simple, un producto escalar simplemente cuenta la cantidad de palabras en común entre la consulta y el documento. Luego, 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” aparece en el documento y en la consulta.

Regla n.o 21: La cantidad de ponderaciones 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 apropiado de complejidad de un modelo, pero esta regla es básicamente todo lo que necesitas saber. Tuve conversaciones en las que las personas cuestionaban que se pudiera aprender algo con mil ejemplos o que alguna vez se necesitaría más de un millón de ejemplos porque se quedan atascados en un determinado método de aprendizaje. La clave es escalar el aprendizaje según el tamaño de los datos:

  1. Si trabajas en un sistema de clasificación de búsqueda, hay millones de palabras diferentes en los documentos y en la consulta y tienes 1, 000 ejemplos etiquetados, debes usar un producto escalar entre las funciones de documentos y consultas, TF-IDF y media docena de otras funciones altamente diseñadas por humanos. 1,000 ejemplos, una docena de funciones.
  2. Si tienes un millón de ejemplos, intersecta las columnas de atributos de consulta y de documentos mediante la regularización y, posiblemente, la selección de atributos. Esto te brindará millones de atributos, pero, con la regularización, tendrás menos. Diez millones de ejemplos, tal vez 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 miles de millones de ejemplos y 10 millones de atributos. La teoría del aprendizaje estadístico rara vez establece límites rígidos, pero ofrece un buen punto de partida.

Al final, usa la regla n.o 28 para decidir qué atributos usar.

Regla n.o 22: Limpia los elementos que ya no uses.

Los atributos sin usar crean deuda técnica. Si descubres que no estás usando un atributo y que no funciona combinarlo con otros atributos, quítalo de la infraestructura. Debes mantener limpia tu infraestructura para que se puedan probar los atributos más prometedores lo más rápido posible. Si es necesario, alguien puede volver a agregar tu función en cualquier momento.

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

Al mismo tiempo, algunas funciones pueden superar su peso. Por ejemplo, si tienes un atributo que cubre solo el 1% de los datos, pero el 90% de los ejemplos que lo tienen 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 el típico usuario final.

Esta es quizás la manera más fácil de que un equipo se enreden. Si bien las pruebas internas (el uso de un prototipo en tu equipo) y la prueba interna (con un prototipo dentro de tu empresa) tienen muchos beneficios, los empleados deben considerar si el rendimiento es correcto. Si bien no se debe usar un cambio que obviamente es malo, cualquier cosa que se parezca razonablemente cercana a la producción debe probarse aún más, ya sea mediante el pago de usuarios no profesionales para que respondan preguntas en una plataforma de participación colectiva o mediante un experimento en vivo con usuarios reales.

Hay dos razones 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 estés demasiado involucrado emocionalmente (p.ej., sesgo de confirmación). El segundo es que tu tiempo es demasiado valioso. Considera el costo de nueve ingenieros en una reunión de una hora y cuántas etiquetas humanas contratadas compran en una plataforma de participación colectiva.

Si realmente quieres comentarios de usuarios, usa metodologías de experiencia del usuario. Crea usuarios de usuarios (puedes encontrar una descripción en Sketching User Experiences de Bill Buxton) al comienzo del proceso y, luego, realiza pruebas de usabilidad (puedes encontrar una descripción en Don’t Make Me Think) de Steve Krug. Los usuarios persona implican crear un usuario hipotético. Por ejemplo, si tu equipo está compuesto solo por hombres, podría ser útil diseñar una persona usuaria femenina de 35 años (completa con atributos de 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 a ver cómo reaccionan a tu sitio (de forma local o remota) en pruebas de usabilidad también puede brindarte una perspectiva nueva.

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

Una de las mediciones más fáciles y, a veces, más útiles que puedes realizar antes de que los usuarios vean tu modelo nuevo es calcular qué tan diferentes son los nuevos resultados 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 clasificación). Si la diferencia es muy pequeña, entonces puedes deducir que habrá pocos cambios, sin necesidad de ejecutar un experimento. Si la diferencia es muy grande, 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 manera cualitativa cómo fue el cambio. Sin embargo, asegúrate de que el sistema sea estable. Cuando compares un modelo consigo mismo, asegúrate de que tenga una diferencia simétrica baja (idealmente cero).

Regla n.o 25: Cuando se eligen los modelos, el rendimiento utilitario prevalece sobre el poder predictivo.

Es posible que tu modelo intente 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 importa más que la predicción en sí misma. Si predices la probabilidad de que un documento sea spam y, luego, tienes un punto límite sobre lo que se bloquea, la precisión de lo que se permite tiene más importancia. La mayoría de las veces, estos dos aspectos deberían coincidir: cuando no es así, es probable que obtenga una pequeña ganancia. Por lo tanto, si hay algún cambio que mejore 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 revisar el objetivo del modelo.

Regla n.o 26: Busca patrones en los errores medidos y crea atributos nuevos.

Supongamos que ves un ejemplo de entrenamiento que el modelo “está equivocado”. 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 podría ser un par en el que un positivo se clasificó en una posición inferior a la negativa. Lo más importante es que se trate de un ejemplo que el sistema de aprendizaje automático sabe que se equivocó y desea corregirlo si tiene la oportunidad. Si le asignas al modelo un atributo que le permite corregir el error, el modelo intentará usarlo.

Por otro lado, si intentas crear un atributo basado en ejemplos que el sistema no considera errores, se ignorará el atributo. 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 bromas menos relevante. Entonces, creas una función para "apps de bromas". Sin embargo, si estás maximizando 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 que el modelo se equivocó, busca tendencias que estén fuera de tu conjunto de atributos actual. Por ejemplo, si parece que el sistema desciende de nivel las publicaciones más largas, agrega la longitud de la publicación. No seas demasiado específico sobre los atributos 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 descubra qué hacer con ellos (consulta la regla n.o 21). Esa es la forma más fácil de obtener lo que quieres.

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

Algunos miembros de tu equipo comenzarán a sentirse frustrados con las propiedades del sistema que no les gustan, que no son capturadas por la función de pérdida existente. 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, pueden hacer que los evaluadores humanos identifiquen estas apps. En este caso, es posible usar datos etiquetados por personas, ya que una fracción relativamente pequeña de las consultas representa una gran parte del tráfico. Si los 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 yexact_query y, luego, calcula la probabilidad de clic de cada documento y de cada consulta. Descubres que su comportamiento es casi idéntico al de tu sistema actual en ambos lados y en las pruebas A/B, por lo que, debido a su simplicidad, lo inicias. Sin embargo, notas que no se muestran apps nuevas. ¿Por qué? Dado que el 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 funcionaría un sistema de este tipo a largo plazo es entrenarlo solo con datos adquiridos cuando el modelo está activo. Esto es muy difícil.

Sesgo entre el entrenamiento y la publicación

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

  • Una discrepancia entre la forma en que manejas los datos en las canalizaciones de entrenamiento y de entrega.
  • Es un cambio en los datos entre el momento del entrenamiento y el de publicación.
  • Un ciclo de retroalimentació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 los datos no generen sesgos inadvertidos.

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

Incluso si no puedes hacerlo para cada ejemplo, hazlo para 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 hicieron esta medición en Google a veces se sorprendieron con los resultados. La página principal de YouTube cambió al registro de funciones en el momento de la entrega con mejoras de calidad significativas y una reducción en la complejidad del código. En este momento, muchos equipos están cambiando su infraestructura.

Regla n.o 30: ¡No los quites de los datos muestreados con ponderación por importancia!

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 se pueden descartar los datos que nunca se mostraron al usuario, la ponderación por importancia es mejor para el resto. La ponderación por importancia significa que si decides que vas a realizar una muestra del ejemplo X con una probabilidad del 30%, le debes aplicar una ponderación de 10/3. Con la ponderación por importancia, se mantienen todas las propiedades de calibración analizadas 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 de la tabla pueden cambiar.

Digamos que unes 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, es posible que cambien los atributos de la tabla. Por lo tanto, la predicción de tu modelo para el mismo documento puede diferir entre el entrenamiento y la entrega. La manera más sencilla de evitar este tipo de problema es registrar los atributos en el momento de la publicación (consulta la regla n.o 32). Si la tabla cambia muy lentamente, también puedes tomar una instantánea de la tabla por hora o todos los días 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 de entrega 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 hacer una búsqueda independiente para cada consulta), mientras que en el procesamiento por lotes, puedes combinar tareas (p.ej., hacer una unión). En la entrega, se realiza el procesamiento en línea, mientras que el entrenamiento es una tarea de procesamiento por lotes. Sin embargo, hay algunas medidas que puedes tomar 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 manera 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, debes ejecutar un método común para establecer un puente entre el objeto legible por humanos específico de tu sistema y cualquier formato que espere el sistema de aprendizaje automático. 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. Esa decisión hará que sea casi imposible para ti compartir el código.

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

En general, mide el rendimiento de un modelo en función de los datos recopilados después de los datos con los que entrenaste el modelo, ya que esto refleja mejor lo que hará el sistema en producción. Si produces un modelo basado en los datos hasta el 5 de enero, prueba el modelo con los datos a partir del 6 de enero. El rendimiento de los datos nuevos no debería ser tan bueno, 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 al ejemplo positivo una puntuación mayor que a un 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 interesantes), haz pequeños sacrificios a corto plazo en el rendimiento para obtener datos muy limpios.

En una tarea de filtrado, los ejemplos que están 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 obtener 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 eso.

Sin embargo, este enfoque introduce un sesgo del muestreo. Puedes recopilar datos más limpios si, en cambio, durante la entrega 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 expuestos pueden convertirse en tus datos de entrenamiento.

Ten en cuenta que si tu filtro bloquea el 95% o más de los ejemplos negativos, este enfoque se vuelve menos viable. Aun así, si deseas medir el rendimiento de publicación, puedes crear una muestra aún más pequeña (p. ej., 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 tu algoritmo de clasificación lo suficiente como para que aparezcan diferentes resultados, cambiaste de manera efectiva los datos que el algoritmo verá en el futuro. Este tipo de desviación aparecerá, y debes diseñar tu modelo en torno a él. Existen varios enfoques diferentes. Todos estos enfoques son una forma de favorecer los datos que tu modelo ya vio.

  1. Permiten lograr una regularización más alta en los atributos que abarcan más consultas, a diferencia de los atributos que solo abarcan una consulta. De esta manera, el modelo favorecerá los atributos específicos de una o varias consultas por sobre los atributos que se generalicen a todas las consultas. Este enfoque puede ayudar a evitar que los resultados muy populares acaben en consultas irrelevantes. Ten en cuenta que esto es lo opuesto a la sugerencia más tradicional de contar con más regularización en columnas de atributos con más valores únicos.
  2. Permitir que solo los atributos tengan ponderaciones positivas Por lo tanto, cualquier función útil será mejor que una "desconocida".
  3. No uses atributos solo de documentos. Esta es una versión extrema de la regla n.o 1. Por ejemplo, incluso si una app determinada es una descarga popular, más allá de cuál sea la búsqueda, no querrás mostrarla en todas partes. Esto se simplifica al no tener atributos solo de documentos. La razón por la que no quieres mostrar una app popular específica en todos lados tiene que ver con la importancia de que todas las apps que quieras estén disponibles. Por ejemplo, si alguien busca "app para observar pájaros", es posible que descargue "Angry Birds", pero definitivamente no fue su intención. Si se muestra esa app, es posible que mejore la tasa de descarga, pero no se satisfacen las necesidades del usuario.

Regla n.o 36: Evita los ciclos de reacción con atributos posicionales.

La posición del contenido afecta drásticamente la probabilidad de que el usuario interactúe con él. Si colocas una app en la primera posición, se hará clic con más frecuencia en ella, y te convendrá de que es más probable que se haga clic en ella. Una forma de lidiar con esto es agregar atributos posicionales, es decir, atributos sobre la posición del contenido en la página. Entrenas el modelo con atributos posicionales y aprende a ponderar, por ejemplo, el atributo "1stposition" en gran medida. Por lo tanto, tu modelo da menos peso a otros factores para ejemplos con "1stposition=true". Luego, durante la publicación, no asignas ninguna instancia al atributo de posición, o le asignas el mismo atributo predeterminado, porque la puntuación de los candidatos antes de haber decidido el orden en el que se muestran.

Ten en cuenta que es importante mantener cualquier atributo posicional un poco separado 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 los atributos de posición con cualquier atributo de documento.

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

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 exclusión. En general, esto siempre existirá y no siempre es malo.
  • La diferencia entre el rendimiento de los datos de exclusión y los datos del "día siguiente". Recuerda que esto siempre existirá. Debes ajustar la regularización para maximizar el rendimiento del día siguiente. Sin embargo, las caídas notables en el rendimiento entre los datos retenidos y los datos del día siguiente pueden indicar que algunos atributos dependen del tiempo y posiblemente degradan el rendimiento del modelo.
  • 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í probablemente indique un error de ingeniería.

Fase III del AA: Crecimiento lento, refinamiento de la optimización y modelos complejos

Existen ciertos indicios de que la segunda fase está llegando a su fin. En primer lugar, las ganancias mensuales comenzarán a disminuir. Las métricas comenzarán a generar compensaciones: en algunos experimentos, verás que algunas aumentan y otras disminuyen. Aquí es donde se pone interesante. Como las ganancias 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 espeluznantes que las secciones anteriores. Hemos visto a muchos equipos pasar por momentos felices de la Fase I y la Fase II de aprendizaje automático. Una vez que llega la Fase III, los equipos deben buscar su propio camino.

Regla n.o 38: No pierdas tiempo en nuevas características si los objetivos no alineados se han convertido en el problema.

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

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

Alice tiene una idea para reducir la pérdida logística de las instalaciones predictivas. Agrega un atributo. La pérdida logística disminuye. Cuando hace 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 lanzamiento, alguien señala que la cantidad de usuarios activos por día disminuye en 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, solo algunos de los cuales se pueden optimizar directamente mediante el AA.

La verdad es que el mundo real no está compuesto por mazmorras ni dragones: no hay "puntos de ataque" que identifiquen el estado de tu producto. El equipo debe usar las estadísticas que recopila para intentar predecir de manera efectiva qué tan bueno será el sistema en el futuro. Deben preocuparse por la participación, los usuarios activos en un 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 en sí mismas, son solo un proxy para objetivos más a largo plazo: satisfacer a los usuarios, aumentar los usuarios, satisfacer a los socios y obtener ganancias, que incluso entonces podrías considerar como valores representativos para tener un producto útil de alta calidad y una empresa próspera de aquí a 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, si 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 para todos los valores de métricas posibles. En particular, considera estas 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, entonces 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 métricas cambiantes pueden o no tener resultados y, por lo tanto, cualquiera de los cambios implica un gran riesgo. Cada métrica cubre un riesgo que preocupa al equipo.

Además, ninguna métrica abarca la preocupación final del equipo, "¿dónde estará mi producto de aquí a 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 crea atributos nuevos puede obtener un flujo constante de lanzamientos en ese entorno. Existe un tipo de aprendizaje automático, el aprendizaje de múltiples objetivos, que comienza a resolver este problema. Por ejemplo, se puede formular un problema de satisfacción de restricciones que tenga límites inferiores en cada métrica y que optimice alguna combinación lineal de métricas. Sin embargo, aun 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 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 lenguaje natural.

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 ensamble de modelos (un “modelo” que combina las puntuaciones de otros modelos) puede funcionar mejor. Para que sea sencillo, cada modelo debe ser un ensamble que solo reciba la entrada de otros modelos o un modelo base que acepte muchos atributos, pero no ambos. 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 los resultados de tus modelos “base” como entradas. También debes aplicar propiedades en estos modelos de ensamble. 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 que los modelos entrantes sean interpretables de forma semántica (por ejemplo, calibrados), para que los cambios de los modelos subyacentes no confundan al modelo de ensamble. Además, asegúrate de que un aumento en la probabilidad predicha de un clasificador subyacente no reduzca la probabilidad predicha del conjunto.

Regla n.o 41: Cuando el rendimiento se estabilice, busca nuevas fuentes de información de manera cualitativa para agregar, en lugar de refinar las señales existentes.

Agregaste cierta información demográfica sobre el usuario. Agregaste información sobre las palabras en el documento. Realizaste la exploración de la plantilla y ajustaste la regularización. No observaste 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 atributos radicalmente diferentes, como el historial de 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 wikidata 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 que esperas de la inversión y expande tus esfuerzos en consecuencia. Al igual que 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 se correlacionen con la popularidad.

La diversidad en un conjunto de contenido 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 de una consulta en particular son más apropiados para esa consulta que para otra. Por lo tanto, estas tres propiedades se definen como diferentes de lo común.

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

Ten en cuenta que, si tu sistema mide clics, el tiempo dedicado, reproducciones, +1, cantidad de veces que se compartió el contenido, etc., tú mides la popularidad del contenido. A veces, los equipos intentan aprender un modelo personal con diversidad. Para la personalización, se agregan funciones que permitirían al sistema personalizar (algunas funciones representan el interés del usuario) o diversificarlas (componentes que indican si este documento tiene alguna función en común con otros documentos mostrados, como el autor o el contenido), y descubre que esos elementos tienen menos peso (o, a veces, un signo diferente) de lo esperado.

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 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 relevancia son valiosas, más allá de la popularidad. Luego, puedes continuar usando el procesamiento posterior o modificar directamente el objetivo en función de la diversidad o la relevancia.

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

Los equipos de Google han tenido mucho interés en tomar un modelo que predice la proximidad de una conexión en un producto y hacer que funcione bien en otro. Tus amigos son lo que son. Por otro lado, observé a varios equipos lidiar con las funciones de personalización en las divisiones de productos. Sí, parece que debería funcionar. Por ahora, parece que no. Lo que a veces 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 indicador en sí mismo.

Existen muchos documentos sobre aprendizaje automático en Google y en otros servicios.

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, Elatsiapis, Glenanders Además, gracias a Kristen Lefevre, Suddha Basu y Chris Berg, que nos ayudaron con una versión anterior. Cualquier error, omisión u (¡oh, no!) opinión impopular que me pertenece.

Apéndice

Existen diversas referencias a los productos de Google en este documento. Para proporcionar más contexto, agregué una breve descripción 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 YouTube Watch Next y de la página principal de YouTube usan modelos de AA para clasificar las recomendaciones de videos. Watch Next recomienda videos para mirar después del que se está reproduciendo en ese momento, mientras que la página principal recomienda videos a los usuarios que exploran la página principal.

Descripción general de Google Play

Google Play tiene muchos modelos que resuelven una gran variedad de problemas. Las apps de la Búsqueda de Play, las recomendaciones personalizadas en la página principal de Play y "Los usuarios también instalados" usan aprendizaje automático.

Descripción general de Google Plus

Google+ utilizó el aprendizaje automático en varias situaciones: clasificar las publicaciones en las "novedades" de las publicaciones que ve el usuario, clasificar las publicaciones de "Lo más interesante" (publicaciones que ahora son muy populares), 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 comerciales el 6 de julio de 2020.