Cómo convertir cualquier producto en un producto de aprendizaje automático

Genial, la primera pregunta que debemos responder es si tu producto está realmente listo para ML. Este es uno de los mayores errores que la gente comete, pensando que cualquier cosa se puede conectar con ML y que cualquier problema se puede resolver con ML. Creo que realmente hay dos preguntas que debes responder. La primera es si tu problema se puede resolver con reglas simples. ¿Puedes pensar en un umbral o es una decisión binaria de si tu problema se puede resolver con una regla simple? La segunda pregunta a considerar es cuál es la escala de tu problema. ¿Necesitas generalizar tu solución a muchas más personas que solo unas pocas cientos? Un ejemplo es si quiero clasificar manzanas de naranjas y todo mi producto se trata solo de clasificar manzanas y naranjas. Tener un pequeño filtro que diga que el naranja es naranja y el rojo es manzana sería un enfoque razonable si tengo 20 usuarios que usan mi producto. Aún no justifica si necesitamos ML. Sin embargo, si tuviera que clasificar diferentes tipos de naranjas que también podrían ser rojizas y diferentes tipos de manzanas que también podrían ser naranjas, necesitaría más que solo el color como regla. Probablemente necesitaría la forma. Probablemente querría utilizar algunas técnicas de visión por computadora y así sucesivamente. Y si puedes responder afirmativamente a ambas preguntas, significa que necesitas más que

Existen muchas reglas que podríamos haber utilizado. Podríamos ver la puntuación de similitud en si el nombre reflejaba o coincidía con el nombre de la persona. Podríamos usar la puntuación de confianza, si el ASR (sistema de reconocimiento de voz) entendía correctamente a Juan. También podríamos usar la relación del usuario con la persona a la que están llamando. Entonces, naturalmente, si alguien es un familiar, es más probable que llame a algunos usuarios, y para otros usuarios, si alguien llama a un Juan con quien se comunican o llaman con frecuencia, es más probable que estén llamando al mismo Juan. También podría variar según la hora del día, si realmente dieron el comando o no. Por lo tanto, para muchos usuarios, podrían estar hablando con otra persona, a veces el ASR capta incorrectamente si el usuario está tratando de llamar a esta persona. ¿Cuál es entonces la probabilidad de ruido? ¿Cuál es la frecuencia con la que hablan con esta persona? ¿Cuál es la puntuación de todos estos módulos previos que básicamente traducen cualquier discurso a texto? Y todas estas eran barreras de reglas, ¿verdad?, y no podían ser abstraídas en una sola regla para nuestros propósitos. Y dado que estas no son solo una regla, y necesitábamos que el modelo realmente aprendiera, no solo a partir de una sola regla de cambio, sino de una data distribución, decidimos aprovechar el ML para este problema. Y este es el problema que les voy a presentar, a través de este ciclo de vida del desarrollo del modelo de ML. Así es como se ve, ¿verdad?, una vez que has decidido, has respondido esta pregunta para tu producto, que necesitas ML para el desarrollo de tu modelo, ¿cómo se ve? Comienza con la recolección de data. La recolección de data implica configurar los conjuntos de características y etiquetas adecuados para el entrenamiento de tu modelo. Y esto puede ser orgánico o artificial. En nuestro caso, para el ejemplo que acabo de dar, como ya estábamos utilizando confirmaciones de los usuarios para decidir si el contacto era el correcto o no, ya teníamos etiquetas orgánicas recolectadas para nuestras características para resolver este problema de ML. Uno puede usar los datos de la era pre-ML, que están anonimizados a partir de sus interacciones de usuarios preexistentes, para entrenar su modelo, o lo que sucede en un escenario, es que puedes crear herramientas para recolectar data para resolver los problemas que estás buscando. Para los fines de esta charla, nos centraremos en la recolección orgánica de data, y cómo puedes obtener data de un producto ya existente y cómo puedes luego utilizar esos data para implementar ML en tu producto. Y esto es cómo se ven nuestras características. Para nuestra recolección orgánica de data, nuestras características incluían la puntuación de confianza ASR, que era si un usuario decía algo, nuestro motor ASR o de reconocimiento de voz lo traducía a texto,

Luego tenemos el motor de reconocimiento de entidades, que toma el nombre del amigo del usuario aquí, John, y luego predice quién es el contacto real. Y esto es el reconocimiento de entidades, que es el reconocimiento de contactos. Una vez que tenemos esto, también tenemos algún otro contexto del usuario. ¿Con qué frecuencia el usuario envía mensajes o llama a esta persona? Esto nos daría contexto para saber si este es un nuevo contacto con el que el usuario nunca ha enviado mensajes, o si es alguien con quien el usuario envía mensajes con frecuencia. Una vez que tenemos estas características, también seleccionamos etiquetas a partir de esa indicación de confirmación, donde si un usuario dijo sí a la indicación de confirmación en nuestro registro anteriordata y terminó realizando una llamada a este contacto, decimos que la etiqueta es positiva. De lo contrario, si el usuario dijo no o cortó la llamada justo cuando se marcó, decimos que es una etiqueta negativa. Ahora que tenemos nuestros data configurados, el siguiente paso es, ¿cómo decidimos qué modelo de ML usar? ¿Cómo decidimos si usar redes neuronales de aprendizaje profundo o quedarnos con los modelos de ML clásicos más simples, como regresión o árboles de decisión, y así sucesivamente?

Para este propósito, sabíamos que queríamos aprender transformaciones no lineales. Teníamos muchas reglas y queríamos que el modelo pudiera aprender planos complejos en esas reglas. También sabíamos que teníamos una mezcla de características categóricas y discretas y también distribucionesdata. Sabíamos que nuestras características categóricas podrían ser dispersas. Podría haber información disponible para algunos usuarios, mientras que otros usuarios podrían no haber proporcionado información, como si alguien es su amigo o familiar, etc. Y dado estos aspectos y el hecho de que queríamos utilizar la menor cantidad de recursos computacionales posible, decidimos utilizar GBDT. GBDT son Árboles de Decisión de Impulso Gradiente.

Estos son más simplificadamente un conjunto de árboles de regresión que se promedian para realizar una tarea de clasificación. Básicamente, aprenden de forma iterativa qué características inyectar en cada uno de estos nodos para generar la etiqueta de la hoja, que es si el usuario es o no es familiar. Y luego, en función de un umbral que el modelo ha aprendido, va a una hoja u otra. En la siguiente decisión, podría aprender si el usuario llamó o no a este amigo en los últimos siete días. Y luego, nuevamente, en función del umbral que aprendió, puede ir al lado izquierdo o derecho y finalmente predecir la etiqueta aprendida por el modelo, diciendo si este es o no es el contacto correcto.

Este es el modelo que usamos. Y ahora que tenemos los data, tenemos el modelo. El siguiente paso es la evaluación. ¿Cómo evaluamos o cómo entendemos que el modelo que usamos realmente funcionó bien? ¿Cómo entrenamos el modelo y qué métricas utilizamos es la siguiente pregunta.

Hay dos tipos de evaluación que voy a cubrir. Uno es la evaluación del modelo fuera de línea y el segundo es en línea. La evaluación del modelo fuera de línea se realiza únicamente en el momento del desarrollo. Se realiza una evaluación cuantitativa y una evaluación cualitativa, que se centra en cómo se ve realmente el data. Por lo tanto, se pueden utilizar una variedad de métricas para evaluar cuantitativamente. Podría ser

Otro punto importante aquí es que, para nuestros propósitos, la precisión fue una de las métricas más importantes, y aquí está la razón. Ya he mencionado este punto antes, pero si realizamos una llamada a la persona equivocada, y ahora, recuerda, nos hemos deshecho de esa confirmación. Y si realizamos una llamada a la persona equivocada, eso significaría que el usuario habría llamado a alguien que no quería, y tendría esta situación embarazosa en la que tendría que explicar cómo su dispositivo inteligente ya no es tan inteligente y terminó llamando a esta persona. Por lo tanto, lo que tuvimos que hacer y optimizar fue reducir nuestro recall incluso hasta el punto en el que la precisión tendía a ser casi del 100%. Muchas veces, el umbral que seleccionas para tu modelo dependerá de tu caso de uso final. Y es posible que tengas que hacer compensaciones donde la precisión y el recall formen una curva. Por lo tanto, es posible que tengas que reducir tu recall para mejorar tu precisión o viceversa. Puede haber otros escenarios en los que quieras obtener la mayor cantidad posible de cosas, aumentar el recall,

Y por último, si evolucionas explícitamente tus características basándote en el análisis cualitativo. Si te das cuenta de que hay más características que puedes inducir en el modelo para mejorarlo, mejorar la recuperación, mejorar la precisión. Por supuesto, necesitas volver a entrenar el modelo.

Y sí, todas estas cosas juntas garantizarán que tengas un modelo de ML robusto al final del día para tus usuarios y asegurarán que tu modelo se adapte a los cambios en la infraestructura y las necesidades de los usuarios. Gracias. Espero que hayas aprendido un poco sobre el ciclo de desarrollo de ML en una empresa de productos como la mía y no dudes en hacer preguntas que puedas tener o si quieres conectarte. Gracias por unirte a nosotros desde los Estados Unidos. Es un poco temprano para ti probablemente. Espero que hayas desayunado. Son las 9:30 a.m. No es tan temprano. Ah, bien. Bien. Bien. No tuviste que poner una alarma para esto. Genial. Vamos a la primera pregunta que viene de nuestro miembro de la audiencia Sanjit y pregunta cómo es tu metodología de IA diferente a los estándares como la metodología SEMA/CRIBS-DM. No tengo idea de lo que significan las siglas. Tal vez, si las dices de nuevo, lo entenderé mejor. De acuerdo. Sanjit, si puedes explicar más, luego intentaremos responder a tu pregunta más adelante. Pasaremos a la siguiente pregunta que viene de Kent dot Ano. Al comienzo de tu charla, dijiste que el problema debía poder resolverse con reglas simples. ¿Cómo saber si esto es cierto? ¿A veces simplemente entrenas el modelo y verificas si resuelve el problema aunque no estés seguro de cuáles son las reglas? Sí, creo que es una excelente pregunta. Y tienes razón. No siempre puedes decir de manera evidente si un problema se puede resolver con reglas simples o no. Hay dos categorías generales de problemas que existen.

Uno son los problemas de clasificación y el segundo son los problemas de generación. Los problemas de clasificación significan que tienes un conjunto de datos y quieres clasificarlo en etiquetas. Suena simple, pero esto puede tener una serie de ramificaciones o aplicaciones en la forma en que se utiliza. Los problemas de generación implican que la máquina recibe un conjunto de datos y tiene que encontrar su propia forma de generar algo. Así que todas esas cosas geniales que ves donde una máquina escribe poesía o una máquina escribe historias, todas esas son problemas de generación. Mientras que cuando ves que una máquina puede detectar objetos como manzanas de naranjas, esos son problemas de clasificación.

Así que muchas veces verás que los problemas de clasificación son aquellos que se pueden resolver con reglas más simples, mientras que los problemas de generación son aquellos en los que quieres confiar en cualquier algoritmo de ML y luego seguir adelante. Y esa suele ser mi forma de decidir si un problema se puede resolver solo con reglas o con ML o no. Esto es básicamente lo que uso.

De acuerdo. Bueno, espero que Kent Ano esté satisfecho con esa respuesta. Solo como recordatorio, hay una sala de discusión sobre visión por computadora en Spatial Chat, así que asegúrate de ir allí después de que terminemos esta sesión de preguntas y respuestas. La siguiente pregunta es de mi co-MC, AJ. Mencionaste los árboles de decisión de refuerzo de gradiente, que son definitivamente buenos, pero ¿no es el refuerzo de gradiente lento para aplicaciones prácticas? ¿No sería mejor un algoritmo como CatBoost o XGBoost en general? Entonces, supongo que desde la perspectiva de cualquier empresa, como cuando estás construyendo machine learning en una gran empresa, idealmente quieres confiar en algoritmos que hayan sido probados y comprobados. Especialmente cuando tienes la cantidad de personas a las que estás implementando ese modelo, como nosotros. Tenemos miles de millones de personas que usan nuestros modelos. Y por lo tanto, muchas veces, sí, un montón de estas metodologías alternativas pueden ser mejores en teoría, pero nos gusta recurrir a aquellas que han demostrado ser mejores en la práctica o aquellas que hemos implementado. Y así, siempre tenemos que ver si un modelo se escala bien o si un modelo es capaz de ser bueno en casos límite y los árboles de decisión de refuerzo de gradiente tanto desde un análisis cualitativo como cuantitativo a lo largo del tiempo, al menos desde la perspectiva del trabajo que se ha establecido, han demostrado ser uno de los mejores enfoques. Dicho esto, ese no es el único enfoque. Podríamos haber utilizado cualquier otro enfoque y haber pasado por el mismo ciclo que ilustré allí. Y lo habríamos hecho, si los árboles de decisión de refuerzo de gradiente no hubieran tenido el rendimiento que tuvieron, superando las expectativas que teníamos del modelo, habríamos vuelto a empezar y habríamos buscado otro modelo. De acuerdo, gracias. Tenemos otra pregunta de un miembro de la audiencia, Mihai, ¿cuál fue tu desafío más difícil mientras trabajabas en Facebook? Esa es una buena. Es una gran pregunta. No, creo que me gusta mucho trabajar en Facebook y creo que esta es una empresa que se impulsa desde abajo, en lugar de desde arriba. Todos los días decidimos en qué estamos emocionados de construir y luego planificamos lo que estamos construyendo y lo único que tenemos que ver es si eso se alinea con el objetivo del equipo y de la empresa. Y por lo tanto, es mucha libertad para construir cosas en las que realmente te importa. Pero debido a la escala de Facebook, también es mucha responsabilidad. Así que cuando estaba en la universidad, hace muchos años, simplemente tomaba cualquier modelo que me gustara, tomaba cualquier data que me gustara y lo introducía en el modelo e intentaba publicar un artículo sin pensar en si estos data están anonimizados correctamente, si estoy protegiendo la privacidad del usuario y demás. Así que ahora creo que, dado que hemos aprendido mucho, todo lo que tengo que hacer en Facebook tiene que considerar todas estas cosas y sus ramificaciones antes de simplemente construir un modelo y desplegarlo.

Creo que todas las buenas barreras de seguridad que tenemos para asegurarnos de proteger los datos que estamos utilizando para el aprendizaje automático de manera apropiada, eso y cómo hacer que un modelo funcione, lo cual depende de estos datos, y equilibrar eso, ha sido una de las cosas más desafiantes y emocionantes de aprender porque ahora hay cosas como el aprendizaje federado, que te dicen cómo puedes caracterizar los datos en el cliente y luego enviarlos al servidor para no comprometer ninguna información que el usuario no quiera compartir y demás, así que hay mucho que aprender, pero creo que es desafiante y emocionante a la vez.

De acuerdo, según entiendo, se trata más de trabajar a la escala de Facebook que de un desafío técnico real y proteger la privacidad y demás. Sí, es bueno escuchar que eso es una prioridad. La siguiente pregunta es de nuestro miembro de la audiencia Reg, ¿cómo es GBDT diferente del aprendizaje por refuerzo? Sí, GBDT es, entonces el aprendizaje por refuerzo se define de manera muy diferente en términos de cómo se representa matemáticamente el problema donde en el aprendizaje por refuerzo básicamente tienes una función de recompensa que defines y luego básicamente intentas asegurarte de que cada acción y aprendes una política para que cada política que tu usuario toma pueda optimizar esa función de recompensa. Y así, ya sea que un usuario o una máquina tome, pueden optimizar esa función de recompensa. GBDT, aunque este problema que estamos abordando, es genial que hayas hecho esta pregunta, se puede modelar muy bien en el aprendizaje por refuerzo porque decidir si llamamos o no a este contacto es decidir una política o una acción para el asistente en este caso. Aún no hemos utilizado el aprendizaje por refuerzo para modelarlo de esa manera. Y usamos GBDT, que es etiquetas predefinidas. No tenemos una estructura de recompensa definida, que intentamos maximizar aquí, mientras que en el aprendizaje por refuerzo tendrías toda la función de recompensa. Probablemente harías Q-learning uno de los algoritmos de aprendizaje por refuerzo para optimizar el mismo problema. Espero que eso responda tu pregunta. Tendría que dar una charla completa y una conferencia sobre aprendizaje profundo, aprendizaje por refuerzo si profundizo más. Bueno, eso es para lo que estamos aquí hoy, ¿verdad? Pero no olvidemos, después de esta sesión de preguntas y respuestas, estarás en tu sala de chat espacial, ¿verdad? Así que las personas que tengan más preguntas o quieran profundizar en tu respuesta, pueden ir allí y discutir más contigo. Una pregunta más de nuestro miembro de la audiencia, Ansall. ¿Cómo manejas el retraso de etiquetas? Por ejemplo, ¿las etiquetas llegan un mes después de los datos de entrenamiento? Gran pregunta. El retraso de etiquetas, y supongo que me imagino cómo manejas cualquier retraso de características o datos que llegan. Hay varias formas de compensar cosas como el retraso de etiquetas. Una podría ser un enfoque de aumento de datos donde dices esto es lo que hipotetizo o calculas tus etiquetas esperadas y básicamente entrenas tu modelo a partir de ahí, y una vez que tengas las etiquetas que estás esperando, luego haces el aprendizaje automático o el aprendizaje activo que mencioné, que es cada vez que tus etiquetas cambian, activas el nuevo entrenamiento del modelo. En este caso, comprometerás el rendimiento del modelo durante el tiempo inicial en que tengas las etiquetas esperadas, el rendimiento será subóptimo. Sin embargo, esto asegurará que tienes un pipeline de modelado independiente y de autoaprendizaje desarrollado. Pero tendría que entender más sobre cómo se ve este retraso de etiquetas para dar una mejor respuesta que podría ser más adecuada para este caso de uso en particular. Y una vez más, mencionaremos tu sala de oradores donde las personas pueden hacer más preguntas o profundizar en esta respuesta. Entonces, Ansoul, si quieres discutir estoy realmente perdido de palabras hoy. Es un buen día para ser un MC cuando estás perdido. Así que si quieres profundizar, ve a la sala de oradores. Y ahora mismo, solo quiero agradecerte por unirte a nosotros y te doy la despedida a tu sala de oradores. Gracias.