Reglas del Machine Learning:Prácticas recomendadas para ML Engineering

Este documento está destinado a ayudar a quienes tienen un conocimiento básico de aprendizaje automático a beneficiarse de las mejores prácticas en aprendizaje automático de Google. Presenta un estilo para el aprendizaje automático, similar a la Guía de estilo de Google C ++ y otras guías populares para prácticas
programación. Si ha tomado una clase de aprendizaje automático, o ha creado o trabajado en un modelo de aprendizaje automático, tiene los antecedentes necesarios para leer este documento.

Terminología
Visión de conjunto
Antes del aprendizaje automático
Regla n. ° 1: No tenga miedo de lanzar un producto sin aprendizaje automático.
Regla n. ° 2: Haga del diseño y la implementación de métricas una prioridad.
Regla n. ° 3: Elija el aprendizaje automático en lugar de una heurística compleja.
ML Fase I: Su primer pipeline
Regla n. ° 4: Mantenga el primer modelo simple y obtenga la infraestructura adecuada.
Regla n. ° 5: pruebe la infraestructura de forma independiente del aprendizaje automático.
Regla n. ° 6: tenga cuidado con los datos descartados al copiar canalizaciones.
Regla n. ° 7: convierta las heurísticas en funciones o manejelas externamente.
Vigilancia
Regla n. ° 8: conozca los requisitos de frescura de su sistema.
Regla n. ° 9: detecte problemas antes de exportar modelos.
Regla # 10: Esté atento a los fallos silenciosos.
Regla n. ° 11: Dé propietarios y documentación de los conjuntos de características.
Tu primer objetivo
Regla n. ° 12: No piense demasiado en qué objetivo elige optimizar directamente.
Regla n. ° 13: elija una métrica simple, observable y atribuible para su primera
objetivo.
Regla n. ° 14: comenzar con un modelo interpretable facilita la depuración.
Regla n. ° 15: filtrado de correo no deseado y clasificación de calidad independientes en una capa de política.
ML Fase II: Ingeniería de funciones
Regla n. ° 16: planifique el lanzamiento y la iteración.
Regla n. ° 17: comience con características directamente observadas e informadas en lugar de aprendidas
caracteristicas.

Terminología

Los siguientes términos aparecerán repetidamente en nuestra discusión sobre el aprendizaje automático efectivo:
Instance: la cosa sobre la que desea hacer una predicción. Por ejemplo, la instancia podría ser una página web que desee clasificar como “sobre gatos” o “no sobre gatos”.
Label: una respuesta para una tarea de predicción, ya sea la respuesta producida por 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”.
Feature: propiedad de una instancia utilizada en una tarea de predicción. Por ejemplo, una página web puede tener una función “contiene la palabra ‘gato’”.
Feature Column: un conjunto de funciones relacionadas, como el conjunto de todos los países posibles en los que puede vivir 1 usuario. Un ejemplo puede tener una o más características presentes en una columna de características. UN
La columna de funciones se denomina “espacio de nombres” en el sistema VW (en Yahoo / Microsoft) o un campo.
Example: una instancia (con sus características) y una etiqueta.
Model: una representación estadística de una tarea de predicción. Entrena un modelo con ejemplos y luego usa el modelo para hacer predicciones.
Metric: un número que le interesa. Puede o no optimizarse directamente.
Objective: una métrica que su algoritmo está tratando de optimizar.
Pipeline: la infraestructura que rodea a un algoritmo de aprendizaje automático. Incluye la recopilación de datos desde el front-end, colocarlos en archivos de datos de entrenamiento, entrenar uno o más modelos y exportar los modelos a producción.

Overview

La mayoría de los problemas a los que se enfrentará son, de hecho, problemas de ingeniería. Incluso con todos los recursos de un gran experto en aprendizaje automático, la mayoría de las ganancias provienen de excelentes funciones, no de excelentes algoritmos de aprendizaje automático. Entonces, el enfoque básico es:
1.Asegúrate de que tu pipeline sea sólida de extremo a extremo
2. comience con un objetivo razonable
3. agregue funciones de sentido común de una manera sencilla
4. asegúrese de que su pipeline se mantenga sólida.
Este enfoque generará mucho dinero y / o hará felices a muchas personas durante un largo período de tiempo. Aléjese de este enfoque solo cuando no haya más trucos simples para llegar más lejos. Agregar complejidad ralentiza futuras versiones.
Una vez que haya agotado los trucos simples, el aprendizaje automático de vanguardia podría estar en su futuro. Consulte la sección sobre proyectos de aprendizaje automático de fase III.

Este documento está organizado en cuatro partes:
1. La primera parte debería ayudarlo 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 su primera canalización.
3. La tercera parte trata sobre el lanzamiento y la iteración mientras se agregan nuevas funciones a su canalización, cómo evaluar los modelos y la formación y el sesgo de servicio.
4. La parte final trata sobre qué hacer cuando llegue a una meseta.
5. Luego, hay una lista de trabajos relacionados y un apéndice con algunos antecedentes sobre los sistemas comúnmente usados ​​como ejemplos en este documento.

Antes de Machine Learning

Regla n. ° 1: no tenga miedo de lanzar un producto sin aprendizaje automático.

El aprendizaje automático es genial, pero requiere datos. En teoría, puede tomar datos de un problema diferente y luego ajustar el modelo para un nuevo producto, pero esto probablemente tendrá un rendimiento inferior a la heurística básica. Si cree que el aprendizaje automático le dará un impulso del 100%, entonces una heurística lo llevará al 50% del camino.
Por ejemplo, si clasifica aplicaciones en un mercado de aplicaciones, puede usar la tasa de instalación o el número de instalaciones. Si está detectando spam, filtre los editores que hayan enviado spam anteriormente.
Tampoco tenga miedo de utilizar la edición humana. Si necesita clasificar los contactos, clasifique los usados más recientemente (o incluso clasifique alfabéticamente). Si el aprendizaje automático no es absolutamente necesario para su producto, no lo use hasta que tenga datos.

Regla n. ° 2: Primero, diseñe e implemente métricas.

Antes de formalizar lo que hará su sistema de aprendizaje automático, realice un seguimiento tanto como sea posible en su sistema actual. Haga esto por las siguientes razones:
1. Es más fácil obtener permiso de los usuarios del sistema antes.
2. Si cree que algo podría ser motivo de preocupación en el futuro, es mejor obtener datos históricos ahora.
3. Si diseña su sistema teniendo en cuenta la instrumentación métrica, las cosas le irán mejor en el futuro. Específicamente, no querrá encontrarse buscando cadenas en los registros para instrumentar sus métricas.
4. Notarás qué cosas cambian y qué sigue igual. Por ejemplo, suponga que desea optimizar directamente los usuarios activos de un día. Sin embargo, durante las primeras manipulaciones del sistema, es posible que observe 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 comparte por lectura, las más por lectura, los comentarios / lectura, los comentarios por usuario, las veces que se comparte por usuario, etc., que utilizan para calcular la bondad de una publicación en el momento de la publicación. Además, tenga en cuenta que es importante contar con un marco experimental, en el que pueda agrupar a los usuarios en depósitos y agregar estadísticas por experimento. Ver
Regla # 12.
Al ser más liberal en la recopilación de métricas, puede obtener una imagen más amplia de su sistema.
¿Notas algún problema? ¡Agrega una métrica para rastrearla! ¿Emocionado por algún cambio cuantitativo en el último lanzamiento? ¡Agrega una métrica para rastrearla!
Regla n. ° 3: elija el aprendizaje automático en lugar de una heurística compleja.
Una simple heurística puede hacer que su producto salga por la puerta. Una heurística compleja no se puede mantener.
Una vez que tenga los datos y una idea básica de lo que está tratando de lograr, pase al aprendizaje automático. Como en la mayoría de las tareas de ingeniería de software, querrá actualizar constantemente su enfoque, ya sea un modelo heurístico o aprendido por máquina, y encontrará que el modelo aprendido por máquina es más fácil de actualizar y mantener (consulte la Regla n. ° 16).

ML Fase I: su primer pipeline

Concéntrese en la infraestructura de su sistema para su primera canalización. Si bien es divertido pensar en todo el aprendizaje automático imaginativo que va a realizar, será difícil averiguar qué está sucediendo si primero no confía en su canalización.
Regla n. ° 4: mantenga el primer modelo simple y obtenga la infraestructura adecuada.
El primer modelo proporciona el mayor impulso a su producto, por lo que no necesita ser sofisticado. Pero se encontrará con muchos más problemas de infraestructura de los que espera. Antes de que alguien pueda usar su nuevo y elegante sistema de aprendizaje automático, debe determinar:

1. Cómo obtener ejemplos para su algoritmo de aprendizaje.
2. Un primer corte en cuanto a lo que significa “bueno” y “malo” para su sistema.

3. Cómo integrar su modelo en su aplicación. Puede aplicar el modelo en vivo o calcular previamente el modelo en ejemplos sin conexión y almacenar los resultados en una tabla. Por ejemplo, es posible que desee preclasificar páginas web y almacenar los resultados en una tabla, pero puede
desea clasificar los mensajes de chat en vivo.

La elección de funciones simples facilita garantizar que:
1. Las funciones llegan correctamente a su algoritmo de aprendizaje.
2. El modelo aprende pesos razonables.
3. Las funciones llegan correctamente a su modelo en el servidor.
Una vez que tenga un sistema que haga estas tres cosas de manera confiable, habrá realizado la mayor parte del trabajo.
Su modelo simple le proporciona métricas de referencia y un comportamiento de referencia que puede utilizar para probar modelos más complejos. Algunos equipos apuntan a un primer lanzamiento “neutral”: un primer lanzamiento que desprioriza explícitamente las ganancias del aprendizaje automático, para evitar distracciones.
Regla n. ° 5: pruebe la infraestructura de forma independiente del aprendizaje automático.
Asegúrese de que la infraestructura se pueda probar y de que las partes de aprendizaje del sistema estén encapsuladas para que pueda probar todo lo que lo rodea. Específicamente:
1. Pruebe la introducción de datos en el algoritmo. Verifique que las columnas de características que se deben completar estén pobladas. Cuando la privacidad lo permita, inspeccione manualmente la entrada a su algoritmo de entrenamiento. Si es posible, verifique las estadísticas de su canalización en comparación con otras, como RASTA.
2. Pruebe la obtención de modelos del algoritmo de entrenamiento. Asegúrese de que el modelo en su entorno de entrenamiento dé la misma puntuación que el modelo en su entorno de servicio (consulte la Regla n. ° 37).
El aprendizaje automático tiene un elemento de imprevisibilidad, así que asegúrese de tener pruebas para el código para crear ejemplos en el entrenamiento y la entrega, y que pueda cargar y usar un modelo fijo durante la entrega. Además, es importante comprender sus datos: consulte Consejos prácticos para el análisis de conjuntos de datos grandes y complejos.
Regla n. ° 6: tenga cuidado con los datos descartados al copiar canalizaciones.
A menudo, creamos una pipeline copiando una pipeline existente (es decir, programación de culto de carga), y la pipeline anterior arroja datos que necesitamos para la nueva pipeline. Por ejemplo, la canalización de Google Plus What’s Hot elimina las publicaciones más antiguas (porque está tratando de clasificar las publicaciones nuevas). Esta canalización se copió para usarla en Google Plus Stream, donde las publicaciones más antiguas todavía son significativas, pero la canalización todavía estaba eliminando 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, porque todos los ejemplos negativos se han eliminado. Ocurrió un problema similar en Play. Mientras trabajaba en Play Apps Home, se creó una nueva canalización que también contenía ejemplos de otras dos páginas de destino (Play Games Home y Play Home Home) sin ninguna función para eliminar la ambigüedad de cada ejemplo.

Regla n. ° 7: convierta las heurísticas en funciones o manejelas externamente.
Por lo general, los problemas que el aprendizaje automático intenta resolver no son completamente nuevos. Existe un sistema para clasificar o clasificar, o cualquier problema que esté tratando de resolver. Esto significa que hay un montón de reglas y heurísticas. Estas mismas heurísticas pueden darle un impulso cuando se ajustan con el aprendizaje automático. Sus heurísticas deben extraerse de cualquier información que tengan, por dos razones. Primero, la transición a un sistema de aprendizaje automático será
más suave. En segundo lugar, por lo general, esas reglas contienen mucha de la intuición sobre el sistema que no desea desechar. Hay cuatro formas de utilizar una heurística existente:
1. Preprocesar usando la heurística. Si la función es increíblemente impresionante, esta es una opción. Por ejemplo, si, en un filtro de spam, el remitente ya ha sido incluido en la lista negra, no intente volver a aprender lo que significa “en la lista negra”. Bloquea el mensaje. Este enfoque tiene más sentido en las tareas de clasificación binaria.
2. Cree una función. Crear directamente una característica a partir de la heurística es genial. Por ejemplo, si usa una heurística para calcular una puntuación de relevancia para el resultado de una consulta, puede incluir la puntuación como el valor de una característica. Más adelante, es posible que desee utilizar técnicas de aprendizaje automático para masajear el valor (por ejemplo, convertir el valor en uno de un conjunto finito de valores discretos, o combinarlo con otras características), pero comience utilizando el valor bruto producido por la heurística.
3. Extraer las entradas brutas de la heurística. Si existe una heurística para las aplicaciones que combina la cantidad de instalaciones, la cantidad de caracteres en el texto y el día de la semana, entonces considere separar estas piezas y agregar estas entradas al aprendizaje por separado. Algunas técnicas que se aplican a los conjuntos se aplican aquí (consulte la Regla # 40).
4. Modifique la etiqueta. Esta es una opción cuando cree que la heurística captura información que no se encuentra actualmente en la etiqueta. Por ejemplo, si está tratando de maximizar la cantidad de descargas, pero también desea contenido de calidad, entonces tal vez la solución sea multiplicar la etiqueta por la cantidad promedio de estrellas que recibió la aplicación. Hay mucho de
espacio aquí para el margen de maniobra. Consulte la sección sobre “Su primer objetivo”.
Tenga en cuenta la complejidad adicional al usar heurística en un sistema de aprendizaje automático. El uso de heurísticas antiguas en su nuevo algoritmo de aprendizaje automático puede ayudar a crear una transición sin problemas, pero piense si existe una forma más sencilla de lograr el mismo efecto.

Monitoring

En general, practique una buena higiene de las alertas, como hacer que las alertas sean procesables y tener una página de tablero.
Regla n. ° 8: conozca los requisitos de frescura de su sistema.
¿Cuánto se degrada el rendimiento si tiene un modelo que tiene un día de antigüedad? ¿Una semana? ¿Un cuarto de edad? Esta información puede ayudarlo a comprender las prioridades de su monitoreo. Si pierde el 10% de sus ingresos si el modelo no se actualiza durante un día, tiene sentido que un ingeniero lo observe continuamente. La mayoría de los sistemas de publicación de anuncios tienen nuevos anuncios que gestionar.

todos los días y debe actualizarse a diario. Por ejemplo, si el modelo ML para Google Play Search no se actualiza, puede tener un impacto en los ingresos en menos de un mes. Algunos modelos de Lo más interesante de Google Plus no tienen un identificador de publicación en su modelo, por lo que pueden exportar estos modelos con poca frecuencia.
Otros modelos que tienen identificadores de publicaciones se actualizan con mucha más frecuencia. También observe que la actualización puede cambiar con el tiempo, especialmente cuando se agregan o eliminan columnas de características de su modelo.
Regla n. ° 9: detecte problemas antes de exportar modelos.
Muchos sistemas de aprendizaje automático tienen una etapa en la que exporta el modelo para servir. Si hay un problema con un modelo exportado, es un problema de cara al usuario. Si hay un problema antes, entonces es un problema de capacitación y los usuarios no lo notarán.
Realice controles de cordura justo antes de exportar el modelo. Específicamente, asegúrese de que el rendimiento del modelo sea razonable según los datos retenidos. O, si tiene preocupaciones persistentes con los datos, no exporte un modelo. Muchos equipos que despliegan modelos continuamente revisan el área debajo del
Curva ROC (o AUC) antes de exportar. Problemas con modelos que no se han exportado
requieren una alerta por correo electrónico, pero los problemas en un modelo de cara al usuario pueden requerir una página. Así que es mejor esperar y estar seguro antes de impactar a los usuarios.
Regla # 10: Esté atento a los fallos silenciosos.
Este es un problema que ocurre más en los sistemas de aprendizaje automático que en otros tipos de sistemas. Suponga que una tabla en particular que se está uniendo ya no se actualiza. El sistema de aprendizaje automático se ajustará y el comportamiento seguirá siendo razonablemente bueno, en decadencia
gradualmente. A veces, se encuentran tablas que estaban desactualizadas durante meses, y una simple actualización mejoró el rendimiento más que cualquier otro lanzamiento ese trimestre. Por ejemplo, la cobertura de una característica puede cambiar debido a cambios en la implementación: por ejemplo, una columna de características podría llenarse en el 90% de los ejemplos y caer repentinamente al 60% de los ejemplos. Play tuvo una vez una mesa que estuvo obsoleta durante 6 meses, y actualizar la mesa solo dio un impulso del 2% en la instalación
Velocidad. Si realiza un seguimiento de las estadísticas de los datos, así como los inspecciona manualmente en ocasiones, puede reducir este tipo de fallas.
Regla n. ° 11: Proporcione los propietarios y la documentación de las columnas de funciones.
Si el sistema es grande y hay muchas columnas de funciones, sepa quién creó o mantiene cada columna de funciones. Si descubre que la persona que entiende una columna de características se va, asegúrese de que alguien tenga la información. Aunque muchas columnas de características tienen nombres descriptivos, es bueno tener una descripción más detallada de qué es la característica, de dónde viene y cómo se espera que ayude.

Tu primer objetivo

está “intentando” optimizar. Aquí distingo entre objetivos y métricas: una métrica es cualquier número que su sistema informa, que puede ser importante o no. Vea también la Regla # 2.
Regla n. ° 12: No piense demasiado en qué objetivo elige optimizar directamente. Quiere ganar dinero, hacer felices a sus usuarios y hacer del mundo un lugar mejor. Hay toneladas de métricas que le interesan y debe medirlas todas (consulte la Regla n. ° 2). Sin embargo,
Al principio del proceso de aprendizaje automático, notará que todos aumentan, incluso aquellos que no optimiza directamente. Por ejemplo, suponga que le importa la cantidad de clics, el tiempo que pasa en el sitio y los usuarios activos diarios. Si optimiza la cantidad de clics, es probable que vea aumentar el tiempo dedicado.
Por lo tanto, manténgalo simple y no piense demasiado en equilibrar diferentes métricas cuando aún puede aumentar fácilmente todas las métricas. Sin embargo, no lleve esta regla demasiado lejos: no confunda su objetivo con la salud máxima del sistema (consulte la Regla n. ° 39). Y, si se encuentra aumentando la métrica optimizada directamente, pero decide no lanzar, es posible que se requiera una revisión objetiva.
Regla # 13: Elija una métrica simple, observable y atribuible para su primer objetivo.
A menudo no sabes cuál es el verdadero objetivo. Crees que sí, pero luego, mientras observas los datos y el análisis lateral de tu antiguo sistema y el nuevo sistema de ML, te das cuenta de que quieres modificarlo. Además, los diferentes miembros del equipo a menudo no pueden ponerse de acuerdo sobre el verdadero objetivo. El objetivo de LD debe ser algo que sea fácil de medir y sea un sustituto del objetivo “verdadero”. Así que entrene en el objetivo de ML simple y considere tener una “capa de política” en la parte superior que le permita agregar lógica adicional (con suerte, lógica muy simple) para hacer la clasificación final.
Lo más fácil de modelar es un comportamiento del usuario que se observa directamente y se atribuye a una acción del sistema:
1. ¿Se hizo clic en este enlace clasificado?
2. ¿Se descargó este objeto clasificado?
3. ¿Este objeto clasificado fue reenviado / respondido / enviado por correo electrónico?
4. ¿Fue calificado este objeto clasificado?
5. ¿Se marcó este objeto mostrado como spam / pornografía / ofensivo?
Evite modelar efectos indirectos al principio:
1. ¿Visitó el usuario al día siguiente?
2. ¿Cuánto tiempo visitó el sitio el usuario?
3. ¿Cuáles fueron los usuarios activos diarios?
Los efectos indirectos son excelentes métricas y se pueden usar durante las pruebas A / B y durante las decisiones de lanzamiento.
Por último, no intente que el aprendizaje automático se dé cuenta:
1. ¿Está satisfecho el usuario con el producto?
2. ¿Está satisfecho el usuario con la experiencia?
3. ¿El producto mejora el bienestar general del usuario?

4. ¿Cómo afectará esto a la salud general de la empresa?
Todos estos son importantes, pero también increíblemente difíciles. En su lugar, use proxies: si el usuario está contento, permanecerá en el sitio por más tiempo. Si el usuario está satisfecho, volverá a visitar 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 está vendiendo y su plan comercial, por lo que no terminamos aquí.
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 los hace más fáciles de depurar que los modelos que utilizan objetivos (pérdida cero, varias pérdidas de bisagra, etc.) que intentan optimizar directamente la precisión de la clasificación o el rendimiento de la clasificación. Por ejemplo, si las probabilidades en el entrenamiento se desvían de las probabilidades pronosticadas en los laterales o al inspeccionar el 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 donde la expectativa promedio predicha es igual a la etiqueta promedio (1 momento calibrado o simplemente calibrado). Si tiene una característica que es 1 o 0 para cada ejemplo, entonces se calibra el conjunto de 3 ejemplos donde esa característica es 1. Además, si tiene una característica que es 1 para cada ejemplo, entonces el conjunto de todos los ejemplos está calibrado.
Con modelos simples, es más fácil lidiar con ciclos de retroalimentación (ver Regla # 36).
A menudo, usamos estas predicciones probabilísticas para tomar una decisión: p. Ej. Clasifique las publicaciones con un valor esperado decreciente (es decir, probabilidad de clic / descarga / etc.). Sin embargo, recuerde que cuando llega el momento de elegir qué modelo utilizar, la decisión es más importante que la probabilidad de los datos dados al modelo (consulte la Regla n. ° 27).
Regla n. ° 15: filtrado de correo no deseado y clasificación de calidad independientes en una capa de política.
La clasificación de calidad es un arte, pero el filtrado de spam es una guerra. Las señales que utiliza para determinar las publicaciones de alta calidad se volverán obvias para aquellos que usan su sistema, y ​​modificarán sus publicaciones para que tengan estas propiedades. Por lo tanto, su clasificación de calidad debe centrarse en clasificar el contenido que se publica de buena fe. No debe descartar al alumno de clasificación de calidad por clasificar el spam en un alto nivel. De manera similar, el contenido “picante” debe manejarse por separado del Ranking de Calidad.
El filtrado de spam es una historia diferente. Debe esperar que las características que necesita generar cambien constantemente. A menudo, habrá reglas obvias que pondrá en el sistema (si una publicación tiene más de tres votos de spam, no la recupere, etcétera). Cualquier modelo aprendido tendrá que actualizarse diariamente, si no más rápido. La reputación del creador del contenido jugará un gran papel.
En algún nivel, la salida de estos dos sistemas deberá integrarse. Tenga en cuenta que filtrar el spam en los resultados de búsqueda probablemente debería ser más agresivo que filtrar el spam en el correo electrónico

ML Fase II: Feature Engineering

En la primera fase del ciclo de vida de un sistema de aprendizaje automático, lo importante es llevar los datos de entrenamiento al sistema de aprendizaje, instrumentar cualquier métrica de interés y crear una infraestructura de servicio. Una vez que tenga un sistema completo en funcionamiento con las pruebas de la unidad y del sistema instrumentadas, comienza la Fase II.
En la segunda fase, hay mucha fruta de bajo perfil. Hay una variedad de características obvias que podrían incorporarse al sistema. Por lo tanto, la segunda fase del aprendizaje automático implica incorporar tantas funciones como sea posible y combinarlas de manera intuitiva. Durante esta fase, todas las métricas deberían seguir aumentando. Habrá muchos lanzamientos, y es un buen momento para atraer a muchos ingenieros que puedan unir todos los datos que necesita para crear un aprendizaje realmente asombroso.
sistema.
Regla n. ° 16: planifique el lanzamiento y la iteración.
No espere que el modelo en el que está trabajando ahora sea el último que lance, o incluso que alguna vez deje de lanzar modelos. Por lo tanto, considere si la complejidad que está agregando con este lanzamiento ralentizará los lanzamientos futuros. Muchos equipos han lanzado un modelo por trimestre o más durante años. Hay tres razones básicas para lanzar nuevos modelos:
1. se le ocurren nuevas funciones,
2. está ajustando la regularización y combinando características antiguas de nuevas formas, y / o
3. está ajustando el objetivo.
Independientemente, darle un poco de amor a un modelo puede ser bueno: mirar los datos que alimentan el ejemplo puede ayudar a encontrar nuevas señales, así como viejas y rotas. Por lo tanto, a medida que construye su modelo, piense en lo fácil que es agregar, eliminar o recombinar características. Piense en lo fácil que es crear una copia nueva de la canalización y verificar que sea correcta. Piense si es posible tener dos o tres copias ejecutándose en paralelo. Por último, no se preocupe si la función 16 de 35 se incluye en esta versión de la canalización. Lo obtendrá el próximo trimestre.
Regla n. ° 17: Comience con características directamente observadas e informadas en lugar de características aprendidas.
Este puede ser un punto controvertido, pero evita muchas trampas. En primer lugar, describamos qué es una función aprendida. Una característica aprendida es una característica generada por un sistema externo (como un sistema de agrupamiento no supervisado) o por el propio alumno (por ejemplo, a través de un modelo factorizado o deep learning.

La discretización consiste en tomar una característica continua y crear muchas características discretas a partir de ella. Considere una característica continua como la edad. Puede crear una característica que sea 1 cuando la edad sea menor de 18, otra característica que sea 1 cuando la edad esté entre 18 y 35, etcétera. No piense demasiado en los límites de estos histogramas: los cuantiles básicos le darán la mayor parte del impacto. Las cruces combinan dos o más columnas de características. Una columna de características, en la terminología de TensorFlow,
es un conjunto de características homogéneas (p. ej., {masculino, femenino}, {EE. UU., Canadá, México}, etc.). Una cruz es una nueva columna de características con características en, por ejemplo, {masculino, femenino} × {EE. UU., Canadá, México}.
Esta nueva columna de características contendrá la característica (hombre, Canadá). Si está usando TensorFlow y le dice a TensorFlow que cree esta cruz para usted, esta característica (masculina, Canadá) estará presente en ejemplos que representan a hombres canadienses. Tenga en cuenta que se necesitan grandes cantidades de datos para aprender modelos con cruces de tres, cuatro o más columnas de características base.
Las cruces que producen columnas de características muy grandes pueden sobreajustarse. Por ejemplo, imagina que estás haciendo algún tipo de búsqueda y tienes una columna de características con palabras en la consulta, y tienes una columna de características con palabras en el documento. Puede combinarlos con una cruz, pero terminará con muchas características (consulte la Regla n. ° 21). Cuando se trabaja con texto, existen dos alternativas. El más draconiano es un producto escalar. Un producto escalar en su forma más simple simplemente cuenta el número de palabras comunes entre la consulta y el documento. Esta característica puede luego ser discretizada. Otro enfoque es una intersección: así, tendremos una característica que está presente si y solo si la palabra “pony” está en el documento y la consulta, y otra característica que está presente si y solo si la palabra “el” está en el documento y la consulta.
Regla n. ° 21: la cantidad de ponderaciones de características que puede aprender en un modelo lineal es aproximadamente proporcional a la cantidad de datos que tiene.
Hay resultados fascinantes de la teoría del aprendizaje estadístico con respecto al nivel apropiado de complejidad para un modelo, pero esta regla es básicamente todo lo que necesita saber. He tenido conversaciones en las que la gente dudaba de que se pudiera aprender algo de mil ejemplos, o de que alguna vez necesitarías más de un millón de ejemplos, porque se atascan en un determinado método de aprendizaje. La clave es escalar su aprendizaje al tamaño de sus datos:
1. Si está trabajando en un sistema de clasificación de búsqueda, y hay millones de palabras diferentes en los documentos y la consulta y tiene 1000 ejemplos etiquetados, entonces debe usar un producto escalar entre las funciones de documento y consulta, TFIDF y media docena
otras características de ingeniería altamente humana. 1000 ejemplos, una docena de funciones.
2. Si tiene un millón de ejemplos, cruce las columnas de características de consulta y documento, utilizando la regularización y posiblemente la selección de características. Esto le dará millones de funciones, pero con la regularización tendrá menos. Diez millones de ejemplos, tal vez cien mil características.
3. Si tiene miles de millones o cientos de miles de millones de ejemplos, puede cruzar las columnas de características con tokens de documentos y consultas, utilizando la selección y regularización de características.
Tendrá mil millones de ejemplos y 10 millones de funciones.
La teoría del aprendizaje estadístico rara vez ofrece límites estrictos, pero ofrece una gran orientación como punto de partida. Al final, use la Regla n. ° 28 para decidir qué funciones usar.

Regla n. ° 22: Limpia las funciones que ya no usas.
Las funciones no utilizadas crean una deuda técnica. Si descubre que no está utilizando una función y que combinarla con otras funciones no funciona, elimínela de su infraestructura. Quiere mantener limpia su infraestructura para poder probar las funciones más prometedoras lo más rápido posible. Si es necesario, alguien siempre puede volver a agregar su función.
Tenga en cuenta la cobertura cuando considere qué funciones agregar o conservar. ¿Cuántos ejemplos cubre la función? Por ejemplo, si tiene algunas funciones de personalización, pero solo el 8% de sus usuarios tiene funciones de personalización, no será muy eficaz.
Al mismo tiempo, algunas funciones pueden superar su peso. Por ejemplo, si tiene una característica que cubre solo el 1% de los datos, pero el 90% de los ejemplos que tienen la característica son positivos, entonces será una gran característica para agregar.

Análisis humano del sistema

Antes de pasar a la tercera fase del aprendizaje automático, es importante centrarse en algo que no se enseña en ninguna clase de aprendizaje automático: cómo mirar 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. ° 23: no es un usuario final típico.
Esta es quizás la forma más fácil para que un equipo se empantane. Si bien existen muchos beneficios para la alimentación de pescado (utilizando un prototipo dentro de su equipo) y la alimentación interna (utilizando un prototipo dentro de su empresa), los empleados deben ver si el rendimiento es correcto. Si bien un cambio que obviamente es malo no debe usarse, cualquier cosa que parezca razonablemente cercana a la producción debe probarse más a fondo, ya sea pagando a los laicos para que respondan preguntas en una plataforma de colaboración colectiva o mediante un experimento en vivo con usuarios reales.
Hay dos razones para esto. La primera es que estás demasiado cerca del código. Puede estar buscando un aspecto particular de las publicaciones o simplemente está demasiado involucrado emocionalmente (por ejemplo, sesgo de confirmación). La segunda es que su tiempo es demasiado valioso. Considere el costo de 9 ingenieros sentados en una reunión de una hora y piense en cuántos sellos humanos contratados compra en una plataforma de crowdsourcing.
Si realmente desea recibir comentarios de los usuarios, utilice las metodologías de experiencia del usuario. Crear usuario
personas (una descripción se encuentra en Designing User Experiences de Bill Buxton) al principio de un proceso y realizan pruebas de usabilidad (una descripción está en Don’t Make Me Think de Steve Krug) más tarde. Las personas de usuario implican la creación de un usuario hipotético. Por ejemplo, si todo su equipo es masculino, podría ser útil diseñar una persona de usuario femenina de 35 años (con funciones de usuario) y observar los resultados que genera en lugar de 10 resultados para hombres de 2540 años. Hacer que personas reales vean su reacción a su sitio (local o remotamente) en las pruebas de usabilidad también puede brindarle una nueva perspectiva.

Regla n. ° 24: Mida el delta entre modelos.
Una de las medidas más fáciles y, a veces, más útiles que puede realizar antes de que los usuarios hayan visto su nuevo modelo es calcular cuán diferentes son los nuevos resultados de la producción. Por ejemplo, si tiene un problema de clasificación, ejecute ambos modelos en una muestra de consultas en todo el sistema y observe 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, puede saber sin realizar un experimento que habrá pocos cambios. Si la diferencia es muy grande, querrá asegurarse de que el cambio sea bueno. Examinar las consultas en las que la diferencia simétrica es alta puede ayudarlo a comprender cualitativamente cómo fue el cambio. Sin embargo, asegúrese de que el sistema sea estable. Asegúrese de que un modelo en comparación con sí mismo tenga una diferencia simétrica baja (idealmente cero).
Regla # 25: Al elegir modelos, el rendimiento utilitario triunfa sobre el poder predictivo.
Su modelo puede intentar predecir la tasa de clics. Sin embargo, al final, la pregunta clave es qué haces con esa predicción. Si lo está utilizando para clasificar documentos, la calidad de la clasificación final es más importante que la predicción en sí. Si predice la probabilidad de que un documento sea spam y luego tiene un límite en lo que está bloqueado, entonces la precisión de lo que está permitido es más importante. La mayoría de las veces, estas dos cosas deben estar de acuerdo: cuando no están de acuerdo, es probable que se trate de una pequeña ganancia. Por lo tanto, si hay algún cambio que mejora la pérdida de registros pero degrada el rendimiento del sistema, busque otra característica. Cuando esto comience a suceder con más frecuencia, será el momento de revisar el objetivo de su modelo.
Regla n. ° 26: busque patrones en los errores medidos y cree nuevas funciones.
Suponga que ve un ejemplo de entrenamiento en el que el modelo se equivocó. En una tarea de clasificación, esto podría ser un falso positivo o un falso negativo. En una tarea de clasificación, podría ser un par donde un positivo
fue clasificado más bajo que negativo. El punto más importante es que este es un ejemplo de que el sistema de aprendizaje automático sabe que se equivocó y le gustaría arreglarlo si tuviera la oportunidad. Si le da al modelo una característica que le permite corregir el error, el modelo intentará usarlo. Por otro lado, si intenta crear una función basada en ejemplos que el sistema no ve como errores, la función se ignorará. Por ejemplo, suponga que en la búsqueda de aplicaciones de Play, alguien busca “juegos gratis”. Supongamos que uno de los mejores resultados es una aplicación de mordaza menos relevante.
Entonces creas una función para “aplicaciones de mordaza”. Sin embargo, si está maximizando la cantidad de instalaciones y las personas instalan una aplicación de mordaza cuando buscan juegos gratuitos, la función “aplicaciones de mordaza” no tendrá el efecto que desea.
Una vez que tenga ejemplos de que el modelo se equivocó, busque tendencias que estén fuera de su conjunto de características actual. Por ejemplo, si el sistema parece estar degradando las publicaciones más largas, agregue la longitud de la publicación. No sea demasiado específico sobre las funciones que agrega. Si va a agregar la longitud de la publicación.

No sea demasiado específico sobre las funciones que agrega. Si va a agregar la longitud de la publicación, no intente adivinar qué significa largo, simplemente agregue una docena de funciones y deje que el modelo descubra qué hacer con ellas (consulte la Regla n. ° 21). Esa es la forma más sencilla de conseguir lo que desea.
Regla # 27: Intente cuantificar el comportamiento indeseable observado.
Algunos miembros de su equipo comenzarán a sentirse frustrados con las propiedades del sistema que no les gustan y 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 piensan que se muestran demasiadas “aplicaciones de mordaza” en Play Search, podrían hacer que los evaluadores humanos identifiquen las aplicaciones de mordaza. (En este caso, puede usar datos con etiquetas humanas porque una fracción relativamente pequeña de las consultas representa una gran fracción del tráfico). Si sus problemas son medibles, puede comenzar a usarlos como funciones, objetivos o métricas. La regla general es “medir primero, optimizar segundo”.
Regla n. ° 28: tenga en cuenta que un comportamiento idéntico a corto plazo no implica un comportamiento idéntico a largo plazo.
Imagine que tiene un nuevo sistema que analiza cada doc_id y exact_query, y luego calcula la probabilidad de hacer clic para cada documento para cada consulta. Encuentra que su comportamiento es casi idéntico al de su sistema actual en ambos lados y en las pruebas A / B, por lo que dada su
simplicidad, lo lanzas. Sin embargo, observa que no se muestran nuevas aplicaciones. ¿Por qué? Bueno, dado que su sistema solo muestra un documento basado en su propio historial con esa consulta, no hay forma de saber que debe mostrarse un nuevo documento.
La única forma 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.

Formación sesgada de servicio

El sesgo de servicio de entrenamiento es una diferencia entre el rendimiento durante el entrenamiento y el rendimiento durante el servicio. Este sesgo puede deberse a:
● una discrepancia entre cómo maneja los datos en la capacitación y las canalizaciones de servicio, o
● un cambio en los datos entre cuando entrenas y cuando sirves, o
● un circuito de retroalimentación entre su modelo y su algoritmo.
Hemos observado sistemas de aprendizaje automático de producción en Google con un sesgo de servicio de formación que afecta negativamente al rendimiento. La mejor solución es monitorearlo explícitamente para que los cambios en el sistema y los datos no introduzcan sesgos inadvertidos.
Regla n. ° 29: la mejor manera de asegurarse de que entrena como lo hace es guardar el conjunto de funciones utilizadas en el momento del servicio y luego canalizar esas funciones a un registro para usarlas en el momento del entrenamiento.
Incluso si no puede hacer esto para cada ejemplo, hágalo por una pequeña fracción, de modo que pueda verificar la coherencia entre la publicación y el entrenamiento (consulte la Regla n. ° 37). Los equipos que han realizado esta medición en Google a veces se sorprendieron con los resultados. Página de inicio de YouTube
cambió a funciones de registro en el momento del servicio con importantes mejoras de calidad y una reducción en la complejidad del código, y muchos equipos están cambiando su infraestructura en estos momentos.
Regla n. ° 30: datos de muestra de peso de importancia, ¡no los deje caer arbitrariamente!
Cuando tiene demasiados datos, existe la tentación de tomar los archivos 112 e ignorar los archivos 1399.
Esto es un error: la eliminación de datos en el entrenamiento ha causado problemas en el pasado para varios equipos (consulte la Regla n. ° 6). Aunque los datos que nunca se mostraron al usuario se pueden eliminar, la ponderación por 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%, ponle una ponderación de 10/3. Con la ponderación de importancia, todas las propiedades de calibración discutidas en la Regla # 14 aún se mantienen.
Regla n. ° 31: tenga en cuenta que si une datos de una tabla durante el entrenamiento y el servicio, los datos de la tabla pueden cambiar.
Supongamos que se une a los identificadores de documentos con una tabla que contiene funciones para esos documentos (como la cantidad de comentarios o clics). Entre el entrenamiento y el tiempo de servicio, las características de la tabla pueden cambiar.
La predicción de su modelo para el mismo documento puede diferir entre el entrenamiento y la publicación.
La forma más fácil de evitar este tipo de problema es registrar las características en el momento de la publicación (consulte la Regla # 32). Si la tabla cambia lentamente, también puede tomar una instantánea de la tabla cada hora o diariamente para obtener datos razonablemente cercanos. Tenga en cuenta que esto aún no resuelve completamente el problema.
Regla n. ° 32: reutilice el código entre su canal de capacitación y su canal de servicio siempre que sea posible.
El procesamiento por lotes es diferente al procesamiento en línea. En el procesamiento en línea, debe manejar cada solicitud a medida que llega (por ejemplo, debe realizar una búsqueda separada para cada consulta), mientras que en el procesamiento por lotes, puede combinar tareas (por ejemplo, hacer una combinación). En el momento de la entrega, está realizando un procesamiento en línea, mientras que la capacitación es una tarea de procesamiento por lotes. Sin embargo, hay algunas cosas que puede hacer para reutilizar el código. Por ejemplo, puede crear un objeto que sea específico para su sistema donde el resultado de cualquier consulta o combinación se pueda almacenar de una manera muy legible por humanos y los errores se puedan probar fácilmente. Luego, una vez que haya reunido toda la información, durante el servicio o el entrenamiento, ejecute un método común para tender un puente entre el objeto legible por humanos
que sea específico de su sistema y del formato que espere el sistema de aprendizaje automático. Esto elimina una fuente de sesgo de servicio de capacitación. Como corolario, trate de no usar dos lenguajes de programación diferentes entre el entrenamiento y el servicio, esa decisión hará que sea casi imposible compartir código.
Regla n. ° 33: si produce un modelo basado en los datos hasta el 5 de enero, pruebe el modelo con los datos del 6 de enero en adelante.
En general, mida el rendimiento de un modelo con los datos recopilados después de los datos con los que entrenó el modelo, ya que esto refleja mejor lo que hará su sistema en producción. Si produce un modelo basado en los datos hasta el 5 de enero, pruebe el modelo con los datos del 6 de enero. Es de esperar que el rendimiento no sea tan bueno con los nuevos datos, pero no debería ser radicalmente peor. Dado que puede haber efectos diarios, es posible que no pueda predecir la tasa de clics promedio o tasa de conversión, pero el área bajo la curva, que representa la probabilidad de dar al ejemplo positivo una puntuación más alta que a un ejemplo negativo, debe estar razonablemente cerca.
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), haga 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. Suponga que tiene un filtro que bloquea el 75% de los ejemplos negativos en la publicación. Es posible que tenga la tentación de extraer datos de entrenamiento adicionales de las instancias que se muestran a los usuarios. Por ejemplo, si un usuario marca un correo electrónico como spam que su filtro dejó pasar, es posible que desee aprender de eso.
Pero este enfoque introduce un sesgo de muestreo. Puede recopilar datos más limpios si, en cambio, durante el servicio, etiqueta el 1% de todo el tráfico como “retenido” y envía todos los ejemplos retenidos al usuario. Ahora su filtro bloquea al menos el 74% de los ejemplos negativos. Estos ejemplos presentados pueden
conviértase en sus datos de entrenamiento.
Tenga en cuenta que si su filtro bloquea el 95% de los ejemplos negativos o más, esto se vuelve menos viable. Aun así, si desea medir el rendimiento de la porción, puede hacer una muestra aún más pequeña (digamos 0,1% o 0,001%). Diez mil ejemplos son suficientes para estimar el rendimiento con bastante precisión.
Regla # 35: Tenga cuidado con el sesgo inherente en los problemas de clasificación.
Cuando cambia su algoritmo de clasificación lo suficientemente radical como para que aparezcan resultados diferentes, ha cambiado efectivamente los datos que su algoritmo verá en el futuro. Este tipo de sesgo aparecerá, y debes diseñar tu modelo alrededor de él. Hay varios enfoques diferentes. Todos estos enfoques son formas de favorecer los datos que su modelo ya ha visto.
1. Tener una mayor regularización en las funciones que cubren más consultas en comparación con las funciones que están activadas para una sola consulta. De esta forma, el modelo favorecerá las características que son específicas de una o algunas consultas sobre las características que se generalizan a todas las consultas. Este enfoque puede ayudar a evitar que los resultados muy populares se filtren en consultas irrelevantes. Nota
que esto es contrario al consejo más convencional de tener más regularización en columnas de características con valores más únicos.
2. Solo permita que las entidades tengan pesos positivos. Por lo tanto, cualquier característica buena será mejor que una característica “desconocida”.
3. No tiene funciones de solo documento. Esta es una versión extrema del # 1. Por ejemplo, incluso si una aplicación determinada es una descarga popular, independientemente de cuál sea la consulta, no desea mostrarla en todas partes. No tener funciones de solo documento lo mantiene simple.

Regla n. ° 36: Evite los bucles de retroalimentación con características posicionales.
La posición del contenido afecta dramáticamente la probabilidad de que el usuario interactúe con él. Si coloca una aplicación en la primera posición, se hará clic en ella con más frecuencia y estará convencido de que es más probable que se haga clic en ella. Una forma de lidiar con esto es agregar características posicionales, es decir, características sobre la posición del contenido en la página. Entrena su modelo con características posicionales y aprende a ponderar, por ejemplo, la característica “1ra posición” en gran medida. Por lo tanto, su modelo le da menos peso a otros factores para ejemplos con “1stposition = true”. Luego, al servir, no le da a ninguna instancia la característica posicional, o les da a todas la misma característica predeterminada, porque está calificando candidatos antes de haber decidido el orden en el que mostrarlos.
Tenga en cuenta que es importante mantener las características posicionales algo separadas del resto del modelo debido a esta asimetría entre el entrenamiento y las pruebas. Hacer que el modelo sea la suma de
una función de las características posicionales y una función del resto de las características es ideal. Por ejemplo, no cruce las características posicionales con ninguna característica del documento.
Regla # 37: Mida el sesgo del entrenamiento / servicio.
Hay varias cosas que pueden causar un sesgo en el sentido más general. Además, puedes dividirlo en varias partes:
1. La diferencia entre el rendimiento en los datos de entrenamiento y los datos reservados. En general, esto siempre existirá y no siempre es malo.
2. La diferencia entre el rendimiento de los datos reservados y los datos del “día siguiente”.
De nuevo, esto siempre existirá. Debe ajustar su regularización para maximizar el rendimiento del día siguiente. Sin embargo, grandes caídas en el rendimiento entre los datos reservados y los datos del día siguiente pueden indicar que algunas funciones son sensibles al tiempo y posiblemente degraden el rendimiento del modelo.
3. La diferencia entre el rendimiento en los datos del “día siguiente” y los datos en vivo. Si aplica un modelo a un ejemplo en los datos de entrenamiento y el mismo ejemplo en la publicación, debería darle exactamente el mismo resultado (consulte la Regla n. ° 5). Por tanto, una discrepancia aquí probablemente indica un error de ingeniería.

ML Fase III: crecimiento lento, optimización
Refinamiento y modelos complejos

Habrá ciertos indicios de que la segunda fase está llegando a su fin. En primer lugar, sus ganancias mensuales comenzarán a disminuir. Comenzará a tener compensaciones entre las métricas: verá que algunas aumentan y otras disminuyen en algunos experimentos. Aquí es donde se pone interesante. Dado que las ganancias son más difíciles de lograr, el aprendizaje automático debe volverse más sofisticado.

Una advertencia: esta sección tiene reglas más bluesky que las secciones anteriores. Hemos visto a muchos equipos pasar por los tiempos felices del aprendizaje automático de las fases I y II. Una vez que se ha alcanzado la Fase III, los equipos deben encontrar su propio camino.
Regla n. ° 38: no pierda el tiempo en nuevas funciones si los objetivos no alineados se han convertido en el problema.
A medida que sus mediciones se estabilicen, su equipo comenzará a analizar problemas que están fuera del alcance de los objetivos de su sistema de aprendizaje automático actual. Como se indicó anteriormente, si los objetivos del producto no están cubiertos por el objetivo algorítmico existente, debe cambiar su objetivo o los objetivos del producto. Por ejemplo, puede optimizar los clics, los plusones o las descargas, pero tomar decisiones de lanzamiento basadas en parte en evaluadores humanos.
Regla n. ° 39: las decisiones de lanzamiento son un indicador de los objetivos a largo plazo del producto.
Alice tiene una idea sobre cómo reducir la pérdida logística de la predicción de instalaciones. Ella agrega una característica. La pérdida logística cae. Cuando realiza un experimento en vivo, ve que la tasa de instalación aumenta.
Sin embargo, cuando asiste a una reunión de revisión de lanzamiento, alguien señala que la cantidad de usuarios activos diarios se reduce 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 múltiples criterios, de los cuales solo algunos pueden optimizarse directamente mediante ML.
La verdad es que el mundo real no son mazmorras y dragones: no hay “puntos de impacto” que identifiquen la salud de su producto. El equipo tiene que utilizar las estadísticas que recopila para intentar predecir de forma eficaz qué tan bueno será el sistema en el futuro. Deben preocuparse por la participación, los usuarios activos de 1 día (DAU), 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 indicador de objetivos a más largo plazo:
usuarios, usuarios en aumento, socios satisfactorios y beneficios, que incluso entonces podría considerar sustitutos por 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 puede elegir entre un algoritmo sofisticado de aprendizaje automático y una heurística simple, si la heurística simple hace un mejor trabajo en todas estas métricas, debería elegir la heurística. Además, no existe una clasificación explícita de todos los valores métricos posibles. Específicamente, considere los siguientes dos escenarios:

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 métricas cambiantes puede o no dar resultado y, por lo tanto, existe un gran riesgo involucrado con cualquiera de los cambios. Cada métrica cubre algún riesgo que concierne al equipo.

Además, ninguna métrica cubre la principal preocupación del equipo, “¿dónde estará mi producto dentro de cinco años”?
Los individuos, por otro lado, 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 utiliza nuevas funciones puede obtener un flujo constante de lanzamientos en ese entorno. Existe un tipo de aprendizaje automático, el aprendizaje multiobjetivo, que comienza a abordar este problema. Por ejemplo, uno puede
Formule 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 entonces, 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 aplicación, es porque se mostró el contenido. Pero es mucho más difícil averiguar por qué un usuario visita su sitio. La forma de predecir el éxito futuro de un sitio en su conjunto es una inteligencia artificial completa, tan difícil como la visión por computadora o el procesamiento del lenguaje natural.
Regla # 40: Mantenga los conjuntos simples.
Los modelos unificados que incorporan características sin procesar y clasifican directamente el contenido son los modelos más fáciles de depurar y comprender. Sin embargo, un conjunto de modelos (un “modelo” que combina las puntuaciones de otros modelos) puede funcionar mejor. Para simplificar las cosas, cada modelo debe ser un conjunto que solo tome la entrada de otros modelos, o un modelo base que tenga muchas características, pero no ambas. Si tiene modelos sobre otros modelos que se entrenan por separado, combinarlos puede resultar en un mal comportamiento.
Use un modelo simple para ensamblar que solo tome como entradas la salida de sus modelos “base”.
También desea aplicar propiedades en estos modelos de conjunto. Por ejemplo, un aumento en la puntuación producido por un modelo base no debería disminuir la puntuación del conjunto. Además, es mejor si los modelos entrantes son semánticamente interpretables (por ejemplo, calibrados) para que los cambios de los modelos subyacentes no confundan el modelo de conjunto. Además, haga cumplir que un aumento en la probabilidad predicha de un clasificador subyacente no disminuye la predicción
probabilidad del conjunto.
Regla # 41: Cuando el desempeño se estanca, busque fuentes de información cualitativamente nuevas para agregar en lugar de refinar las señales existentes.
Agregó información demográfica sobre el usuario. Ha agregado información sobre las palabras en el documento. Ha pasado por la exploración de plantillas y ha ajustado la regularización. No ha visto un lanzamiento con más de un 1% de mejora en sus métricas clave en algunos trimestres. ¿Ahora que?
Es hora de comenzar a construir la infraestructura para características radicalmente diferentes, como el historial de documentos a los que este usuario ha accedido en el último día, semana o año, o datos de otro
propiedad. Utilice entidades de wikidata o algo interno de su empresa (como el gráfico de conocimiento de Google). Utilice el aprendizaje profundo. Empiece a ajustar sus expectativas sobre cuánto le devuelve espere en la inversión y amplíe sus esfuerzos en consecuencia. Como en cualquier proyecto de ingeniería, debe sopesar el beneficio de agregar nuevas funciones con el costo de una mayor complejidad.
Regla n. ° 42: no espere que la diversidad, la personalización o la relevancia estén tan correlacionadas con la popularidad como cree.
La diversidad en un conjunto de contenido puede significar muchas cosas, siendo la diversidad de la fuente del contenido 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 consulta en particular son más apropiados para esa consulta que para cualquier otra. Por lo tanto, estas tres propiedades se definen como diferentes de las ordinarias.
El problema es que lo ordinario tiende a ser difícil de superar.
Tenga en cuenta que si su sistema mide los clics, el tiempo dedicado, los relojes, los +1, las veces que se comparte, etc., está midiendo la popularidad del contenido. Los equipos a veces intentan aprender un modelo personal
con diversidad. Para personalizar, agregan características que permitirían al sistema personalizar (algunas características que representan el interés del usuario) o diversificar (características que indican si este documento tiene alguna característica en común con otros documentos devueltos, como el autor o el contenido), y encontrar que esos las características obtienen menos peso (o algunas 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, puede hacer un posprocesamiento para aumentar la diversidad o relevancia. Si ve que aumentan los objetivos a más largo plazo, puede declarar que la diversidad / relevancia es valiosa, además de la popularidad. Luego, puede continuar utilizando su posprocesamiento o modificar directamente el objetivo en función de la diversidad o la relevancia.
Regla # 43: Tus amigos tienden a ser iguales en diferentes productos. Tus intereses tienden a no serlo.
Los equipos de Google han ganado mucha tracción al tomar un modelo que predice la cercanía de una conexión en un producto y hacer que funcione bien en otro. Tus amigos son quienes son. Por otro lado, he visto a varios equipos luchar con las funciones de personalización en las divisiones de productos. Sí, parece que debería funcionar. Por ahora, no parece que lo sea. Lo que a veces ha funcionado es usar datos sin procesar de una propiedad para predecir el comportamiento de otra. También,
Tenga en cuenta que incluso saber que un usuario tiene un historial en otra propiedad puede ayudar. Por ejemplo, la presencia de actividad del usuario en dos productos puede ser indicativa en sí misma.

Trabajos relacionados

There are many documents on machine learning at Google as well as externally.

● Machine Learning Crash Course: an introduction to applied machine learning

● Machine Learning: A Probabilistic Approach by Kevin Murphy for an understanding of the field of machine learning ● Practical Advice for the Analysis of Large, Complex Data Sets: a data science approach to thinking about data sets.

● Deep Learning by Ian Goodfellow et al for learning nonlinear models ● Google paper on technical debt, which has a lot of general advice.

● Tensorflow Documentation