Reunir un equipo de AA
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Los proyectos de AA requieren equipos con miembros que tengan una variedad de habilidades, experiencia y responsabilidades relacionadas con el aprendizaje automático. Estos son los roles más comunes que se encuentran en los equipos de AA típicos:
Rol |
Conocimientos y habilidades |
Producto final |
Gerente de producto de AA |
Los gerentes de productos de AA tienen un conocimiento profundo de las fortalezas y debilidades del AA, así como del proceso de desarrollo de AA. Alinean los problemas empresariales con las soluciones de AA trabajando directamente con el equipo de AA, los usuarios finales y otras partes interesadas. Crean la visión del producto, definen casos de uso y requisitos, y planifican y priorizan proyectos.
|
Documento de requisitos del producto (PRD).
|
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 producto de AA, alinear 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.
|
Documentos de diseño, planes de proyectos y evaluaciones de rendimiento.
|
Científico de datos |
Los científicos de datos usan el análisis cuantitativo y estadístico para extraer información y valor de los datos. Ayudan a identificar y probar atributos, crear prototipos de modelos y ayudar con la interpretabilidad de los modelos.
|
Informes y visualizaciones de datos que responden preguntas comerciales a través de análisis estadísticos
|
Ingeniero de AA |
Los ingenieros de AA diseñan, compilan, producen y administran modelos de AA.
Son ingenieros de software sólidos con un conocimiento profundo de las tecnologías y prácticas recomendadas de AA.
|
Se implementó un modelo con suficiente calidad de predicción 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 el entrenamiento y la publicación de modelos. Los ingenieros de datos son responsables de los datos en todo el proceso de desarrollo del AA.
|
Canalizaciones de datos completamente puestas en producción con la supervisión y las alertas necesarias
|
Ingeniero de operaciones de desarrolladores (DevOps) |
Los ingenieros de DevOps desarrollan, implementan, escalan y supervisan
la infraestructura de entrega de los modelos de AA.
|
Es un proceso automatizado para entregar, supervisar, probar y generar alertas sobre el comportamiento de un modelo.
|
Los proyectos de AA exitosos tienen equipos con cada rol bien representado. En equipos más pequeños, las personas deberán controlar las responsabilidades de varios roles.
Establece prácticas de equipo
Debido a que los roles, las herramientas y los frameworks varían mucho en el desarrollo de AA, es fundamental establecer prácticas comunes a través de una excelente documentación del proceso. Por ejemplo, un ingeniero podría pensar que solo obtener los datos correctos es suficiente para comenzar a entrenar un modelo, mientras que un ingeniero más responsable validará que el conjunto de datos esté anonimizado correctamente y documentará sus metadatos y procedencia. Asegurarse de que los ingenieros compartan definiciones comunes para los procesos y los patrones de diseño reduce la confusión y aumenta la velocidad del equipo.
Documentación del proceso
Los documentos de procesos deben definir las herramientas, la infraestructura y los procesos que el equipo
usará para el desarrollo de AA. Los documentos de procesos bien elaborados ayudan a alinear a los miembros nuevos y existentes del equipo. Debe 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 una característica o etiqueta de entrada en los datos de entrenamiento?
- ¿Cómo personalizamos la canalización de generación, entrenamiento y evaluación de datos?
- ¿Cómo cambio la arquitectura del modelo para que se adapte a los cambios en los atributos o las etiquetas de entrada?
- ¿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 hay algún problema con nuestro modelo?
- ¿De qué sistemas upstream dependen nuestros modelos?
- ¿Cómo hago que mi SQL sea mantenible y reutilizable?
Más preguntas posibles
Modelo
¿Puedo entrenar modelos en diferentes conjuntos de datos en la misma canalización, como para el perfeccionamiento?
¿Cómo agrego un nuevo conjunto de datos de prueba a mi canalización?
Capacitación
¿Cómo verifico la predicción del modelo en un ejemplo creado a mano?
¿Cómo puedo encontrar, examinar y visualizar ejemplos en los que el modelo cometió
errores?
¿Cómo determino qué característica fue la más responsable de una predicción determinada?
¿Cómo puedo saber qué atributos tienen el mayor impacto en las predicciones dentro de una muestra determinada?
¿Cómo puedo calcular o trazar 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 puedo comparar 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?
Puesta en producción, supervisión y mantenimiento
Creo que creé un buen modelo. ¿Cómo puedo lanzarlo en producción?
¿Cómo puedo verificar que mi modelo nuevo se esté ejecutando correctamente en producción?
¿Puedo obtener el historial de las evaluaciones del modelo 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 que menciona algo sobre el modelo.
¿Qué debo hacer?
Canalizaciones
¿Cómo podría 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?
SQL
Infraestructura
Comunicación
Recuerde
Lo que constituye "prácticas recomendadas de AA" puede diferir entre empresas, equipos y personas. Por ejemplo, algunos miembros del equipo podrían considerar que las Colab experimentales son el producto final principal, mientras que otros querrán trabajar en R. Es posible que algunos tengan pasión por la ingeniería de software, que otros piensen que la supervisión es lo más importante, y que otros conozcan buenas prácticas de producción de funciones, pero quieran usar Scala. Todos tienen “razón” desde su propia perspectiva y, si se orienta correctamente, la combinación será una fuente de energía. De lo contrario, puede ser un desastre.
Establecer las herramientas, los procesos y la infraestructura que usará el equipo antes de escribir una línea de código puede ser la diferencia entre que el proyecto falle después de dos años o se lance con éxito un trimestre antes de lo previsto.
Debido a la ambigüedad y la incertidumbre inherentes al AA, los administradores de personal deben establecer expectativas claras y definir las entregas con anticipación.
Cuando determines las expectativas y los entregables, ten en cuenta cómo se
evaluarán si un proyecto o enfoque no tiene é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 raro que los miembros del equipo pasen
semanas investigando 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.
Comprueba tu comprensión
¿Cuál es el motivo principal para tener una excelente documentación de procesos y establecer prácticas comunes?
Aumentar la velocidad del proyecto
Correcto. Tener una buena documentación del proceso y establecer prácticas comunes reduce la confusión y optimiza el proceso de desarrollo.
Establecer prácticas recomendadas en toda una empresa
Debido a que el desarrollo del AA varía de un proyecto a otro, los equipos suelen establecer sus propios conjuntos de prácticas recomendadas para trabajar de manera eficaz y aumentar su velocidad.
Asegúrate de que todos los ingenieros del equipo tengan el mismo nivel de experiencia.
Los equipos de AA suelen tener ingenieros con una variedad de habilidades y
conocimientos. La documentación de procesos ayuda a los ingenieros a alinearse con las prácticas recomendadas para aumentar su velocidad.
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[null,null,["Última actualización: 2025-07-27 (UTC)"],[[["\u003cp\u003eMachine learning projects necessitate diverse teams with specialized roles like ML product managers, data scientists, and ML engineers, to address various aspects of development and deployment.\u003c/p\u003e\n"],["\u003cp\u003eComprehensive process documentation is crucial for ML teams to establish common practices, ensure smooth collaboration, and enhance project velocity by reducing confusion and streamlining workflows.\u003c/p\u003e\n"],["\u003cp\u003eProcess documentation should cover key questions regarding data handling, model development, training, evaluation, and productionization to guide the team's approach and decision-making.\u003c/p\u003e\n"],["\u003cp\u003eEstablishing clear expectations, deliverables, and evaluation criteria for team members is essential, emphasizing contributions beyond project success due to the inherent uncertainties in ML development.\u003c/p\u003e\n"],["\u003cp\u003eSuccessful ML teams foster a collaborative environment where diverse perspectives and expertise are valued, enabling efficient problem-solving and innovative solutions.\u003c/p\u003e\n"]]],[],null,["# Assembling an ML team\n\nML projects require teams with members who have a range of skills, expertise,\nand responsibilities related to machine learning. These are the most common\nroles found on typical ML teams:\n\n| Role | Knowledge and skills | Main deliverable |\n|----------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|\n| ML product manager | ML product managers have a deep understanding of ML strengths and weaknesses and the ML development process. They align business problems to ML solutions by working directly with the ML team, end-users, and other stakeholders. They create the product vision, define use cases and requirements, and plan and prioritize projects. | Product requirements document (PRD). |\n| Engineering manager | Engineering managers achieve business goals by setting, communicating, and achieving team priorities. Like ML product managers, they align ML solutions to business problems. They set clear expectations for team members, conduct performance evaluations, and assist with career and professional development. | Design docs, project plans, and performance evaluations. |\n| Data scientist | Data scientists use quantitative and statistical analysis to extract insights and value from data. They help to identify and test features, prototype models, and help with model interpretability. | Reports and data visualizations that answer business questions through statistical analysis. |\n| ML engineer | ML engineers design, build, productionize, and manage ML models. They are strong software engineers with a deep understanding of ML technologies and best practices. | Deployed model with sufficient prediction quality to meet business goals. |\n| Data engineer | Data engineers build data pipelines for storing, aggregating, and processing large amounts of data. They develop the infrastructure and systems for collecting and transforming raw data into useful formats for model training and serving. Data engineers are responsible for the data across the entire ML development process. | Fully productionized data pipelines with the necessary monitoring and alerting. |\n| Developer operations (DevOps) engineer | DevOps engineers develop, deploy, scale, and monitor the serving infrastructure for ML models. | An automated process for serving, monitoring, testing, and alerting on a model's behavior. |\n\nSuccessful ML projects have teams with each role well\nrepresented. In smaller teams, individuals will need to handle the\nresponsibilities for multiple roles.\n\n\nEstablish team practices\n------------------------\n\nBecause the roles, tools, and frameworks vary widely in ML\ndevelopment, it's critical to establish common practices through\nexcellent process documentation. For example, one engineer might\nthink that just getting the right data is sufficient to begin training a model,\nwhile a more responsible engineer will validate that the dataset is anonymized\ncorrectly and document its metadata and provenance. Making sure engineers share\ncommon definitions for processes and design patterns reduces confusion and\nincreases the team's velocity.\n\n### Process documentation\n\nProcess docs should define the tools, infrastructure, and processes the team\nwill use for ML development. Good process docs help align new and current\nteam members. They should answer the following types of questions:\n\n- How is the data generated for the model?\n- How do we examine, validate, and visualize the data?\n- How do we modify an input feature or label in the training data?\n- How do we customize the data generation, training, and evaluation pipeline?\n- How do I change the model architecture to accommodate changes in input features or labels?\n- How do we obtain testing examples?\n- What metrics will we use to judge model quality?\n- How do we launch our models in production?\n- How will we know if something is wrong with our model?\n- What upstream systems do our models depend on?\n- How do I make my SQL maintainable and reusable?\n\n#### More potential questions\n\n**Model**\n\n-\n Can I train models on different datasets in the same\n pipeline, like for fine-tuning?\n\n-\n How do I add a new test dataset to my pipeline?\n\n**Training**\n\n-\n How do I check the model's prediction on a hand-crafted example?\n\n-\n How do I find, examine, and visualize examples where the model made\n mistakes?\n\n-\n How do I determine which feature was most responsible for a given\n prediction?\n\n-\n How do I understand which features have the most impact on\n predictions within a given sample?\n\n-\n How do I compute or plot model predictions on a chosen dataset or\n sample?\n\n-\n How do I compute standard metrics for my model's predictions on a\n chosen dataset?\n\n-\n How do I develop and compute custom metrics?\n\n-\n How do I compare my model with other models offline?\n\n-\n Can I perform meta-analysis for multiple model evaluations in a single\n development environment?\n\n-\n Can I compare the current model with the one from 10 months ago?\n\n**Productionization, monitoring, and maintenance**\n\n-\n I think I created a good model. How can I launch it in production?\n\n-\n How do I verify that my new model is running in production correctly?\n\n-\n Can I get the history of model evaluations over time?\n\n-\n How will I know when something is wrong with the model?\n\n-\n I got assigned a page/bug mentioning something about the model.\n What should I do?\n\n**Pipelines**\n\n-\n How could I customize the data generation/training/evaluation\n pipeline?\n\n-\n When and how should I create a completely new pipeline?\n\n**SQL**\n\n-\n I need SQL to generate some data. Where should I put it?\n\n**Infrastructure**\n\n-\n How does our model serving work? Is there a diagram?\n\n-\n What upstream systems does my model depend on that I should be\n aware of?\n\n**Communication**\n\n-\n I can't figure something out. Who (and how) should I contact?\n\n### Keep in mind\n\nWhat constitutes \"ML best practices\" can differ between companies, teams, and\nindividuals. For\nexample, some team members might consider experimental Colabs as the main\ndeliverable, while others will want to work in R. Some might have a passion for\nsoftware engineering, someone else thinks monitoring is the most important\nthing, yet someone else is aware of good feature productionization practices but\nwants to use Scala. Everyone is \"right\" from their own perspective and if\nsteered correctly, the mix will be a powerhouse. If not, it can be a mess.\n\nEstablishing the tools, processes, and infrastructure the team will use before\nwriting a line of code can be the difference between the project failing after\ntwo years or successfully launching a quarter ahead of schedule.\n\nPerformance evaluations\n-----------------------\n\nDue to the ambiguity and uncertainty inherent in ML, people managers need to set\nclear expectations and define deliverables early.\n\nWhen determining expectations and deliverables, consider how they'll be\nevaluated if a project or approach isn't successful. In other words, it's\nimportant that a team member's performance isn't directly connected to the\nsuccess of the project. For example, it's not uncommon for team members to spend\nweeks investigating solutions that are ultimately unsuccessful. Even in these\ncases, their high-quality code, thorough documentation, and effective\ncollaboration should contribute positively toward their evaluation.\n\n### Check Your Understanding\n\nWhat is the primary reason for having excellent process documentation and establishing common practices? \nIncrease project velocity. \nCorrect. Having good process documentation and establishing common practices reduces confusion and streamlines the development process. \nEstablish best practices across a company. \nBecause ML development varies from project to project, teams typically establish their own sets of best practices to work effectively and increase their velocity. \nEnsure all engineers on the team have the same level of expertise. \nML teams typically have engineers with a variety of skills and knowledge. Process documentation helps engineers align on best practices to increase their velocity."]]