Los proyectos de AA requieren equipos con miembros que tengan una variedad de habilidades, conocimientos y responsabilidades relacionados con el aprendizaje automático. Estos son los roles más comunes en los equipos de AA típicos:
| Rol | Conocimientos y habilidades | Entregable principal |
|---|---|---|
| Gerente de producto de AA | Los gerentes de producto de AA tienen un conocimiento profundo de las fortalezas y debilidades del AA, y del proceso de desarrollo del AA. Alinean los problemas empresariales con las soluciones de AA a través de sus direccionamiento con el equipo de AA, los usuarios finales y otras partes interesadas. Crean la visión del producto, definen los casos de uso y requisitos, y planifican y priorizan los proyectos. |
Documento de requisitos del producto (PRD). Para ver un ejemplo de una PRD de detección de anomalías del AA, consulta PRD de detección de anomalías. |
| Gerente de ingeniería | Los gerentes de ingeniería logran los objetivos comerciales estableciendo, comunicando y logrando las prioridades del equipo. Al igual que los gerentes de productos de AA, alinean las soluciones de AA con los problemas empresariales. Establecen expectativas claras para los miembros del equipo, realizan evaluaciones de rendimiento y ayudan con el desarrollo profesional y profesional. |
Documentos de diseño, planes de proyectos y evaluaciones de rendimiento. Para ver un ejemplo de un documento de diseño de AA, consulta go/ml-design-doc-example. |
| Científicos de datos | Los científicos de datos usan análisis cuantitativos y estadísticos para extraer información y valor de los datos. Ayudan a identificar y probar funciones, crear prototipos de modelos y ayudar con la interpretabilidad de los modelos. | Informes y visualizaciones de datos que responden a preguntas comerciales mediante análisis estadísticos. |
| Ingeniería de AA | Los ingenieros de AA diseñan, compilan, producen y administran modelos de AA. Son ingenieros de software capacitados con un conocimiento profundo de las tecnologías de AA y las prácticas recomendadas. | Modelo implementado con calidad de predicción suficiente para cumplir con los objetivos comerciales. |
| Ingeniero de datos | Los ingenieros de datos crean canalizaciones de datos para almacenar, agregar y procesar grandes cantidades de datos. Desarrollan la infraestructura y los sistemas para recopilar y transformar datos sin procesar en formatos útiles para entrenar y entregar modelos. Los ingenieros de datos son responsables de los datos durante todo el proceso de desarrollo del AA. | Canalizaciones de datos completamente productivas con la supervisión y las alertas necesarias. |
| Ingeniero de operaciones para desarrolladores (DevOps) | Los ingenieros DevOps desarrollan, implementan, escalan y supervisan la infraestructura de entrega para los modelos de AA. | Un proceso automatizado para la entrega, la supervisión, las pruebas y las alertas del comportamiento de un modelo. |
Los proyectos de AA exitosos tienen equipos con cada función bien representada. En equipos más pequeños, las personas deberán asumir las responsabilidades de varios roles. En estas instancias, las herramientas de AutoML como Vertex AI pueden ayudarte a través de la automatización de tareas de AA, como el desarrollo, la comprensión y la implementación de los modelos.
Establecer prácticas de equipo
Debido a que las funciones, las herramientas y los frameworks varían ampliamente en el desarrollo del AA, es fundamental establecer prácticas comunes a través de una excelente documentación sobre los procesos. Por ejemplo, un ingeniero podría pensar que basta con obtener los datos correctos para comenzar a entrenar un modelo, mientras que un ingeniero más responsable validará que el conjunto de datos se anonimiza de manera correcta y documentará su origen y sus metadatos. Asegurarse de que los ingenieros compartan definiciones comunes de los procesos y patrones de diseño reduce la confusión y aumenta la velocidad del equipo.
Documentación de procesos
Los documentos de los procesos deben definir las herramientas, la infraestructura y los procesos que el equipo usará para el desarrollo de AA. La buena documentación de procesos ayuda a alinear a los miembros nuevos y actuales del equipo. Deben responder los siguientes tipos de preguntas:
- ¿Cómo se generan los datos para el modelo?
- ¿Cómo examinamos, validamos y visualizamos los datos?
- ¿Cómo modificamos un atributo de entrada o una etiqueta en los datos de entrenamiento?
- ¿Cómo personalizamos la generación de datos, el entrenamiento y la canalización de evaluación?
- ¿Cómo cambio la arquitectura del modelo para que se adapte a los cambios en los atributos de entrada o las etiquetas?
- ¿Cómo obtenemos ejemplos de pruebas?
- ¿Qué métricas usaremos para juzgar la calidad del modelo?
- ¿Cómo lanzamos nuestros modelos en producción?
- ¿Cómo sabremos si algo anda mal con nuestro modelo?
- ¿De qué sistemas upstream dependen nuestros modelos?
- ¿Cómo hago para que mi SQL se pueda mantener y reutilizar?
En go/ml-list-of-questions, encontrarás un documento de Google con una lista de estas preguntas.
Más preguntas potenciales
Modelo¿Puedo entrenar modelos en diferentes conjuntos de datos en la misma canalización, para un ajuste?
¿Cómo agrego un nuevo conjunto de datos de prueba a mi canalización?
¿Cómo puedo verificar la predicción del modelo en un ejemplo hecho a mano?
¿Cómo puedo encontrar, examinar y visualizar ejemplos de errores en el modelo?
¿Cómo puedo determinar qué atributo fue el más responsable de una predicción determinada?
¿Cómo puedo saber qué atributos tienen el mayor impacto en las predicciones de una muestra determinada?
¿Cómo calculo o plasma las predicciones del modelo en un conjunto de datos o una muestra elegidos?
¿Cómo calculo las métricas estándar para las predicciones de mi modelo en un conjunto de datos elegido?
¿Cómo desarrollo y calculo métricas personalizadas?
¿Cómo comparo mi modelo con otros modelos sin conexión?
¿Puedo realizar un metaanálisis para varias evaluaciones de modelos en un solo entorno de desarrollo?
¿Puedo comparar el modelo actual con el de hace 10 meses?
Creo que creé un buen modelo. ¿Cómo puedo lanzarla en producción?
¿Cómo verifico que mi modelo nuevo se esté ejecutando correctamente en producción?
¿Puedo obtener el historial de las evaluaciones de modelos a lo largo del tiempo?
¿Cómo sabré si hay algún problema con el modelo?
Se me asignó una página o un error en el que mencionaba algo sobre el modelo. ¿Qué debo hacer?
¿Cómo puedo personalizar la canalización de generación, entrenamiento y evaluación de datos?
¿Cuándo y cómo debo crear una canalización completamente nueva?
Necesito SQL para generar algunos datos. ¿Dónde debería colocarla?
¿Cómo funciona nuestra entrega de modelos? ¿Hay un diagrama?
¿De qué sistemas upstream depende mi modelo que debo conocer?
No puedo descifrar algo. ¿Con quién (y cómo) debo comunicarme?
Recuerda
Lo que constituye “prácticas recomendadas para el AA” puede diferir entre empresas, individuos y equipos. Por ejemplo, algunos miembros del equipo podrían considerar Colabs experimentales como el resultado entregable principal, mientras que otros querrán trabajar en R. Algunos pueden tener pasión por la ingeniería de software, otros piensan que la supervisión es lo más importante, pero alguien más conoce las buenas prácticas de producción de atributos, pero desea usar Scala. Todos tenemos " razón" desde su propia perspectiva y, si se siguen correctamente, la combinación será una potencia. Si no es así, puede ser un desastre.
Establecer las herramientas, los procesos y la infraestructura que el equipo usará antes de escribir una línea de código puede ser la diferencia entre que un proyecto falle después de dos años o que se lance con éxito un trimestre antes de lo previsto.
Evaluaciones de rendimiento
Debido a la ambigüedad y la incertidumbre inherentes al AA, los gerentes de personal deben establecer expectativas claras y definir las entregas con anticipación.
Al determinar las expectativas y los entregables, considera cómo se evaluarán si un proyecto o enfoque no tienen éxito. En otras palabras, es importante que el rendimiento de un miembro del equipo no esté directamente conectado con el éxito del proyecto. Por ejemplo, no es inusual que los miembros del equipo dediquen semanas a investigar soluciones que, en última instancia, no tienen éxito. Incluso en estos casos, su código de alta calidad, su documentación exhaustiva y su colaboración eficaz deberían contribuir de manera positiva a su evaluación.