Esta charla será una guía paso a paso sobre cómo utilizar el aprendizaje automático para reemplazar un sistema basado en reglas para los consumidores. Discutiremos cuándo está bien usar ML, cómo construir estos modelos con datos inteligentes, evaluarlos sin conexión y finalmente cómo validar esta evaluación para implementar estos modelos en sistemas de producción. Además, ilustraremos diversas estrategias de autoaprendizaje/aprendizaje interactivo que se pueden utilizar en sistemas de producción para automatizar cómo los modelos se enseñan a sí mismos para mejorar.
Video Summary and Transcription
En esta charla, un ingeniero de ML de Facebook comparte ideas sobre cuándo usar ML y un caso de éxito de Facebook. El orador discute el proceso de utilizar ML para las llamadas de Facebook Portal, incluida la recopilación de datos y la selección de modelos. Se enfatiza la importancia de la precisión y la exhaustividad en los modelos de ML, así como la necesidad de evaluación en línea y aprendizaje activo. La charla también aborda los desafíos de la protección de datos y el retraso en las etiquetas en el desarrollo de modelos de ML.
Available in English
1. Introduction to ML and Product Readiness
Short description:
Hola a todos. Soy Shivani, una ingeniera de ML en Facebook. En esta charla, les guiaré sobre cuándo usar ML y compartiré un caso de uso exitoso de Facebook. Para determinar si tu producto está listo para ML, considera dos preguntas: ¿Se puede resolver tu problema con reglas simples? ¿Cuál es la escala de tu problema? Por ejemplo, clasificar manzanas de naranjas puede requerir solo un filtro de color para una pequeña base de usuarios. Pero si necesitas clasificar diferentes tipos de naranjas y manzanas, necesitarás más que solo el color. Si ambos criterios se cumplen, se necesita ML.
y hoy voy a compartir con ustedes cómo convertir casi cualquier producto en ML. Esta charla va a ser más práctica, donde les mostraré cuándo es adecuado usar ML. Vamos a discutir un caso de uso en el que yo en Facebook utilicé ML y con éxito, y les guiaré a través del ciclo de desarrollo de modelos de ML.
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
2. Using ML for Facebook Portal Calls
Short description:
Vamos a ver un escenario de la vida real en el que se utiliza ML para las llamadas de Facebook Portal. El objetivo era realizar llamadas precisas prediciendo el destinatario previsto. Inicialmente, se utilizó una selección basada en reglas, pero resultó engorrosa. Se aprovechó el ML para aprender de la distribución de datos y superar las limitaciones de las reglas. El ciclo de desarrollo del modelo de ML involucra la recolección de datos, la configuración de conjuntos de características y etiquetas, y el uso de datos orgánicos de interacciones de productos preexistentes. Las características para la recolección de datos orgánicos incluyen puntuaciones de confianza ASR.
solo reglas simples y tu problema está listo para escalar, necesitas ML para tu producto. Vamos a ver un escenario de la vida real de cómo usamos esto para Facebook Portal. Yo trabajaba en el equipo de Portal de Facebook y una de nuestras características destacadas era la función de llamadas. El usuario llegaba y decía: `Hola, Portal, llama a Juan`, y la idea era que el dispositivo entendiera quién es Juan en tu lista de amigos. Y si hay varios Juanes, entonces debería desambiguar quién es el Juan correcto y luego realizar una llamada a esa persona. Y hay que tener en cuenta que el costo de equivocarse es alto, ya que podrías llamar a la persona equivocada y dejar una llamada perdida. Por lo tanto, la opción aquí es ser muy preciso. Y cuando comenzamos, el flujo que teníamos era que el usuario iniciaba este comando, Portal entendería quién es el Juan más probable, y esto se basaba simplemente en reglas. Elegiríamos el contacto principal que obtuviéramos y luego emitiríamos una confirmación. Y si el usuario decía sí, confirmo, llámalo, lo llamaríamos; de lo contrario, no lo haríamos. Pero este era un proceso muy engorroso, ¿verdad? El usuario tenía que ingresar, seleccionar, confirmar, seleccionar a quién estaban llamando, a menudo interactuar y tocar en la interfaz de usuario. Y esto iba en contra de la experiencia de que el usuario interactuara sin manos con este dispositivo inteligente. Por lo tanto, tuvimos que abordar el problema de cómo predecir quién es el Juan real, para que el usuario no tuviera que hacer todo este trabajo por sí mismos.
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,
3. Selección y Evaluación del Modelo de ML
Short description:
El motor NLU determina la intención del usuario, mientras que el motor de reconocimiento de entidades predice el contacto. Se considera el contexto del usuario, como la frecuencia de los mensajes. Las etiquetas se seleccionan en función de las indicaciones de confirmación. Para elegir el modelo de ML, queríamos transformaciones no lineales y optamos por GBDT. GBDT es un conjunto de árboles de regresión que aprende características de forma iterativa y predice el contacto. La evaluación involucra métodos en línea y fuera de línea, utilizando métricas cuantitativas como precisión y recall.
lo convierte en texto y genera una puntuación de confianza. Luego tenemos el motor NLU o el motor de detección de intenciones que toma este texto como entrada y devuelve la intención del usuario. Por lo tanto, el usuario podría haber querido realizar una llamada, enviar un mensaje, etc.
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
4. Métricas y Análisis
Short description:
Para tareas de clasificación, se utilizan puntuaciones de precisión. Para tareas de generación de lenguaje natural, se utilizan puntuaciones de similitud. Las métricas cuantitativas como la precisión y el recall son importantes, pero el análisis cualitativo también es crucial. Si todas las etiquetas en el conjunto de datos son iguales, el modelo puede funcionar bien en esos datos pero fallar en nuevos datos. Realizamos tanto análisis cuantitativo como cualitativo y logramos una precisión de más del 95%. Nuestros modelos funcionaron como se esperaba.
precisión, recall, puntuación F, podría ser exactitud. Estas son para tareas más de clasificación. Para tareas de generación de lenguaje natural, se pueden utilizar puntuaciones de similitud. Para tareas de detección de similitud, se pueden utilizar puntuaciones de similitud. Y esto depende del modelo que uses. Para nuestros propósitos, utilizamos métricas cuantitativas de precisión y recall. Y también utilizamos análisis cualitativo. Por lo tanto, el análisis cualitativo es muy importante durante el desarrollo. Y aquí está el motivo. Tus métricas cuantitativas te dirán si la precisión o el recall del modelo es excelente. Sin embargo, ¿qué sucede si todas las etiquetas que tenías eran unas? Entonces, todo tudata set, tenías 20 muestras, y todo tudata set era una sola etiqueta. El modelo aprenderá muy fácilmente que siempre tengo que predecir uno para tener buenos resultados en estedata set. Y luego, cuando pruebas el modelo en másdata, que tiene otras etiquetas, el modelo podría comenzar a predecir esas incorrectamente. Pero en tu conjunto de datos de prueba, esta etiqueta que tenías en abundancia es, digamos, 80%. Y esta nueva etiqueta que el modelo nunca ha visto antes es, digamos, 20%, tu exactitud sigue siendo del 80%. Y a menos que analices cualitativamente cómo está funcionando tu modelo y qué está prediciendo, dirías que tu exactitud es del 80%, lo cual es genial cuantitativamente, pero no escala bien cualitativamente. Por lo tanto, para nuestros propósitos, realizamos tanto análisis cuantitativo como cualitativo, nuestro modelo funcionó muy bien. Y pudimos obtener una precisión alta, de más del 95%. Y cualitativamente, nuestros modelos parecen hacer exactamente lo que queríamos que hicieran.
5. Importancia de la Precisión y el Recall
Short description:
La precisión fue crucial para nuestros propósitos. Realizar una llamada a la persona equivocada sin una confirmación podría llevar a situaciones embarazosas. Optimizamos para obtener una alta precisión, incluso a costa de reducir el recall. El umbral para el modelo depende del caso de uso y puede ser necesario hacer compensaciones entre la precisión y el recall.
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,
6. Evaluación en línea y Aprendizaje Activo
Short description:
Ahora que hemos recopilado datos, modelado el modelo y evaluado las métricas fuera de línea, el siguiente paso es la evaluación en línea. Producimos el modelo escribiendo un envoltorio que abstrae el binario del modelo y lo hace disponible en tiempo de ejecución. La evaluación en línea implica desarrollar métricas, como la tasa de éxito de las llamadas, y anti-métricas, como las cancelaciones de llamadas. Implementamos el modelo en un conjunto más pequeño de usuarios para realizar pruebas A-B y monitorear las métricas. Si las métricas se comportan como se espera, lanzamos progresivamente el modelo a un grupo más grande. Si no es así, analizamos el problema y realizamos los cambios necesarios. Finalmente, el aprendizaje activo es crucial para mantener las métricas en línea a lo largo del tiempo. El reentrenamiento se activa cuando los módulos upstream cambian.
mientras que es posible que tengas margen para disminuir la precisión. Y así, genial. Ahora, hemos data recopilado, el modelo ha sido modelado, las métricas fuera de línea se ven bien. ¿Qué sigue? Lo siguiente es la evaluación en línea. Entonces, ahora que estamos seguros de que nuestro modelo está funcionando bien, estamos listos para implementarlo. ¿Cómo lo sabemos? ¿Cómo producimos este modelo? ¿Cómo sabemos que realmente funciona bien para los usuarios reales? ¿Simplemente lo lanzamos a todos? No, no lo hacemos. Tenemos un segundo paso antes de hacer eso. Entonces, para nuestros propósitos, producimos el modelo. Escribimos un envoltorio que básicamente abstrae el binario del modelo y lo hace disponible en runtime con una función de predicción donde podemos derivar las características que el modelo aprendió en tiempo real. Entonces, ahora que tenemos una solicitud, el usuario hizo una solicitud, convertimos esa solicitud en todas esas características que discutimos antes. y llamamos a esta función de predicción en runtime con estas características. Devolvemos una etiqueta y luego en runtime vemos si el usuario realmente terminó realizando esa llamada o la canceló esa llamada. Y así es como llegamos a la evaluación en línea. Y desarrollamos estos trucos de corrección de usuario proxy. Estas métricas cambian constantemente porque las métricas pueden ser algo como el aumento de la tasa de éxito de las llamadas y la tasa de éxito de las llamadas se define como la llamada que el usuario inició y luego completó y no simplemente abandonó. Y también podemos definir anti-métricas. Por ejemplo, el aumento de las cancelaciones de llamadas es una anti-métrica. No queremos que eso suceda. Y luego lo implementamos en un conjunto de usuarios, inicialmente un conjunto más pequeño de usuarios, esto se llama prueba A-Btesting. Vemos cómo se comportan estas métricas. Y si estas métricas se comportan como esperamos que se comporten, entonces seguimos adelante y lanzamos el modelo a un grupo más grande de personas y así sucesivamente hasta que lo hayamos lanzado a todos. Si no es así, volvemos a la mesa de dibujo, vemos cuál es el problema. Vemos si es ajuste de hiperparámetros lo que necesitamos cambiar, y así sucesivamente, para determinar exactamente dónde el modelo no está funcionando bien. Finalmente, uno pensaría que ya has recopiladodata datos, has modelado ML, has evaluado fuera de línea, lo has implementado, has realizado una evaluación en línea excelente, ¿qué sigue? Hay un paso más que a menudo se pasa por alto, que es el aprendizaje activo o aprendizaje iterativo o mantenimiento del modelo. Entonces, ¿qué es ese aprendizaje? El aprendizaje activo puede significar muchas cosas en este contexto. Pero en este contexto, se refiere exclusivamente a cómo el modelo mantiene sus métricas en línea a lo largo del tiempo en diferentes usuarios y así sucesivamente. Entonces, en el aprendizaje activo, solo activamos el reentrenamiento del modelo cuando cambian los modules upstream. En nuestro caso, teníamos un módulo NLU que detectaba la intención, teníamos un módulo ASR que convertía el habla a texto. Y dependíamos de las confianzas de estos modules como características. Entonces, ¿qué sucede si mi modelo NLU cambia y el significado de su confianza cambia? ¿Qué sucede si la confianza que antes predecía como 0.5 ahora es 0.6, mi modelo comenzará a hacer predicciones incorrectas si todavía está en la distribución anterior mientras que la distribución del modelo más nuevo cambió. Entonces, si alguno de los modelos upstream que informan las características de los modelos aguas abajo o tu modelo cambia, necesitas
QnA
Retraining and AI Methodology
Short description:
Si hay un cambio en un número significativo de usuarios, deberás volver a entrenar tu modelo. La evolución de las características basada en el análisis cualitativo requiere el reentrenamiento del modelo. Esto garantiza un modelo de ML robusto que se adapta a los cambios en la infraestructura y las necesidades de los usuarios. Gracias por unirte a nosotros. Pasemos a la primera pregunta de Sanjit sobre la metodología de IA. La siguiente pregunta es de Kent dot Ano sobre cómo determinar si un problema se puede resolver con reglas simples.
para activar el reentrenamiento. Si hay un cambio en un número significativo de usuarios. A menudo, habrá diferentes patrones que el modelo aprende en función de los usuarios actuales en los que está aprendiendo. Entonces, si hay un cambio en ellos, deberás volver a entrenar tu modelo.
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.
Classification and Generation Problems
Short description:
Los problemas de clasificación implican clasificar un conjunto de datos en etiquetas, mientras que los problemas de generación requieren que la máquina genere algo por sí misma. Los problemas de clasificación a menudo se pueden resolver con reglas más simples, mientras que los problemas de generación requieren algoritmos de ML. Los árboles de decisión de refuerzo de gradiente han demostrado ser efectivos en aplicaciones prácticas, considerando la escala y los casos límite. Otros algoritmos pueden ser mejores en teoría, pero la practicidad y el rendimiento probado son clave. En Facebook, priorizamos enfoques probados y comprobados. Uno de los desafíos más difíciles en Facebook es equilibrar la libertad de construir con la responsabilidad de proteger la privacidad del usuario y considerar la escala de la empresa.
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.
Protección de Datos y Retraso de Etiquetas
Short description:
Trabajar con la protección de datos y hacer que los modelos de ML funcionen a gran escala ha sido desafiante y emocionante. GBDT es diferente del aprendizaje por refuerzo en términos de representación del problema y funciones de recompensa. Aún no hemos utilizado el aprendizaje por refuerzo para nuestro problema. El retraso de etiquetas se puede manejar mediante técnicas de aumento de datos y autoaprendizaje. Únete a la sala del orador para más discusiones.
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.
