Cómo construir proyectos de data science en el mundo real.

Lecciones aprendidas al cometer varios errores

Introducción

La mayoría de los artículos sobre cómo “completar” una tarea de ciencia de datos generalmente discuten cómo escribir un algoritmo para resolver un problema. Por ejemplo, cómo clasificar un documento de texto o pronosticar datos financieros. Aprender a hacer estas cosas puede ser un conocimiento vital para un data science si entra dentro de sus competencias. Sin embargo, la tarea es solo una pequeña parte del proceso de que completa un proyecto de ciencia de datos en el mundo real. Incluso si puede codificar la solución perfecta para un problema de clasificación de texto de varias clases, ¿es realmente valioso para la empresa? ¿Cuál es la solución actual al problema y qué punto de referencia debe superar para que el usuario pueda confiar en su resultado? Cuando el algoritmo está en funcionamiento y funcionando, ¿recibe información para comprender si la producción produce continuamente resultados utilizables?

En este post, quiero establecer algunas pautas para desarrollar y llevar a cabo proyectos de ciencia de datos efectivos y sostenibles. Esta guía es una lista que surgió después de cometer varios errores en mis propios proyectos de ciencia de datos, así como ver a otros hacer los suyos propios. Algo de esto no se aplicará a todos los data science porque no todo esto caerá dentro de sus competencias. Sin embargo, he estado en un equipo en el que no teníamos el lujo de un analista de negocios dedicado, gerente de producto o incluso un gerente de ciencia de datos. Significaba que tenía que asumir algunas de las responsabilidades de estos roles yo mismo y, a menudo, no hacer un gran trabajo al respecto. Pero fue una valiosa experiencia de aprendizaje y he aquí algunas de las cosas que aprendí.

  • Mención especial: Independientemente de si está de acuerdo o no con mi waffling, debería ver el video en este artículo sobre cómo hacer ciencia de datos impulsada por las partes interesadas por Max Shron, el jefe de ciencia de datos en Warby Parker . Es sorprendente y establece un gran listón para hacer buenos proyectos de ciencia de datos en el mundo real.

¿Qué preguntas deben abordarse para que un proyecto se considere exitoso?

Cuando surge una solución a un problema, me resulta útil para ver qué aspecto tiene el éxito (aquí asumimos que ya sabemos cuál es el problema, pero no subestimemos lo difícil que puede ser identificar un problema que su equipo actualmente está configurado para poder resolverlo). Esto me ayuda a desarrollar estrategias para llegar al objetivo final. En este caso, quiero escribir un conjunto de preguntas que puedo responder de inmediato si el proyecto es exitoso. Aquí están:

  1. ¿Por qué estás haciendo el proyecto? Es decir. ¿Qué valor aporta el proyecto y cómo contribuye a los objetivos más amplios del equipo de ciencia de datos?
  2. ¿Quiénes son los principales interesados ​​del proyecto?
  3. ¿Cuál es la solución actual al problema?
  4. ¿Existe un simple y una solución efectiva al problema que se puede realizar rápidamente?
  5. ¿Ha hecho un esfuerzo para involucrar a las personas adecuadas con suficiente aviso e información?
  6. ¿Ha verificado su solución con otra persona?
  7. hizo un esfuerzo para asegurar que el código sea robusto?
  8. ¿Ha hecho un esfuerzo para asegurarse de que el proyecto pueda ser fácilmente comprendido y entregado a alguien más?
  9. ¿Cómo está validando su modelo en producción? [19659009] ¿Cómo reúnes los comentarios de la solución?

En mi experiencia, si estas preguntas se pueden responder adecuadamente entonces es probable que el proyecto sea exitoso. Puede que este no sea siempre el caso y esta lista puede no ser exhaustiva dependiendo del proyecto, pero al menos es un buen punto de partida.

Kate Strachnyi tiene un conjunto de 20 preguntas para Pregúntenos antes de iniciar el análisis de datos en un artículo muy corto si decide que prefiere no abrirse paso a través de mi gigantesco fart cerebral (no lo culpo).

Los pasos a continuación ayudan a abordar cada uno de estos preguntas.

Guía de 5 pasos para proyectos de ciencia de datos

Paso 1: Obtenga una evaluación inicial del valor potencial del proyecto

  • ¿Por qué? Te ayuda a priorizar proyectos. Debería ser capaz de explicar adecuadamente por qué un proyecto debería completarse antes que otro. También nos permite comprender cómo el proyecto se alinea con los objetivos del equipo y la empresa. Además, esto también proporcionará una guía sobre qué métrica deberíamos optimizar para el modelo.
  • ¿Qué implica esto? Cuantificación aproximada de los beneficios, p. dinero ahorrado, aumento de los ingresos, reducir el tiempo dedicado al trabajo manual. El argumento en contra de esto es que es difícil de hacer y no siempre cuantificable. Mi respuesta es: si usted o sus partes interesadas no pueden entender el valor del proyecto, ¿por qué se permiten a sí mismos oa sus partes interesadas desperdiciar su tiempo? [19659027] El valor no tiene que ser perfecto, solo una estimación aproximada. Este paso también implica determinar quiénes son los principales interesados ​​directos
  • ¿Qué sucede si no se hace? Podemos pasar años haciendo un proyecto del que nadie se beneficia . Un ejemplo de un proyecto que vi que podría haberse hecho con un mejor alcance fue cuando el equipo de ciencia de datos se encargó de identificar una lista de personas que tenían más probabilidades de beneficiarse al ser contactados por nuestro equipo de marketing. Se construyó un modelo, pero decidimos pasar un par de meses mejorándolo. A pesar de que el nuevo modelo daba mejores resultados, el equipo tuvo que ajustar su umbral porque a la empresa no le preocupaban los puntajes que se generaban para cada cliente, sino que querían asegurarse de que se contactaran con un número fijo de personas. Por lo tanto, es discutible que el tiempo dedicado a mejorar el modelo no tenía sentido y que lo hubiéramos sabido si analizáramos mejor el proyecto con las partes interesadas. (Se podría argumentar que el número fijo de personas contactadas es en realidad un segmento mejor debido a un modelo mejor, pero esto no se midió, por lo que no sabemos si este es el caso).
  • ¿Qué es? el resultado de este paso? Una estimación cuantitativa aproximada del valor del proyecto acompañado de un breve párrafo que proporciona más contexto (un resumen ejecutivo del proyecto). Es importante tener en cuenta que, según la empresa y el proyecto, solo la ganancia de valor percibida de tener un modelo de datos es suficiente para que la empresa considere que el proyecto sea un éxito. En cuyo caso, una estimación cuantitativa no es necesaria. Pero eso es más acerca de política de la compañía y solo puede suceder por tanto tiempo antes de que necesite números duros para mostrar el valor de su equipo.
  • Recursos útiles: Este artículo titulado “ A La forma simple de modelar el ROI de cualquier característica nueva “ayuda mucho”. Proporcione una fórmula simple: ROI esperado = (alcance de usuarios * valor de uso * nuevo o incremental para empresas) – costo de desarrollo . Otras lecturas útiles son “ Priorizando el trabajo de ciencias de datos ” y “ Producto y priorización

Paso 2: Determine el enfoque actual / Crear modelo de línea de base

Fuente: Crear una línea de base de sentido común Primero
  • ¿Por qué hacerlo? El enfoque actual nos da un punto de referencia para el objetivo. Todos los modelos útiles deberían superar el enfoque actual, si es que hay alguno. Si no hay una solución actual al problema, entonces debes desarrollar un modelo de referencia. El modelo de referencia es esencialmente la solución al problema sin aprendizaje automático. Es probable que una solución compleja solo proporcione valor incremental, por lo que deberá evaluar si realmente vale la pena construir algo más complejo.
  • ¿Qué implica esto? Hable con las partes interesadas para determinar qué hacen actualmente y qué éxito tienen. Es probable que no midan su tasa de éxito, por lo que es algo que tendrá que estimar / calcular. La construcción de un modelo de referencia no debe involucrar ningún método complejo / involucrado. Debería ser bastante rápido y rudimentario. Probablemente utilizando métodos de conteo.
  • ¿Cuál es el resultado de esta fase? Un número de evaluación inicial del desempeño requerido para ser exitoso / útil para los interesados. Una evaluación de si vale la pena construir un modelo complejo.
  • Qué sucede si no se hace: Podría perder tiempo construyendo un modelo complejo que, en el mejor de los casos, probablemente no valía la pena el tiempo invertido en obtener el precisión, o en el peor, ni siquiera es el mejor enfoque actual. Esto fue algo que se perdió cuando construimos nuestro motor de recomendación. No verificamos que el algoritmo fuera mejor que una referencia razonable (recomendando el contenido más popular). Pudo haber sido que el algoritmo de recomendación no proporcionó el valor suficiente para justificar hacerlo cuando lo hicimos.
  • Recursos para ayudar: Los artículos titulados “ crean una línea de base de sentido común primero “y” Siempre comience con un modelo estúpido, sin excepciones. “son buenas lecturas que enfatizan este punto.

3. Tener una discusión de “Equipo”

  • ¿Por qué hacerlo? Llegados a este punto, ha llegado a la conclusión de que vale la pena realizar este proyecto (paso 1) y que el éxito es factible (paso 2), por lo que es hora de hablar con las personas involucradas para que el proyecto tenga éxito, p. los ingenieros y / u otros data science son candidatos obvios. Debería estar más claro sobre qué código debe escribir, qué datos necesita, qué debe probar, qué medida de rendimiento usar, qué modelos se aproxima debe probar. Es fácil pensar que sabes lo que necesitas por tu cuenta, pero tener conversaciones con otros a menudo puede ayudar a resaltar cosas que te perdiste o cosas que podrían mejorarse. No subestime la importancia de tener personas con diferentes puntos de vista que contribuyan a la discusión.
  • ¿Qué implica? Habla con al menos otro data science y muéstrales los resultados que has obtenido hasta ahora. Tal vez tengan ideas sobre cómo puede mejorar su idea. Es vital que hagas esto antes de comenzar con el modelo porque es menos probable que cambies tu modelo una vez que esté escrito. También es posible que el data science con el que hable sea el encargado de revisar el código y, por lo tanto, los ayude con el contexto. Habla con el ingeniero que participará en la producción de tu trabajo. Probablemente necesiten saber qué esperar y pueden tener sugerencias que harán que el código de producción sea mucho más fácil.
  • ¿Cuál es el resultado de esta fase? ¡Nada concreto! Solo algo para garantizar que la calidad sea tan buena como la primera vez. Asegúrese de que las personas relevantes estén al tanto y a bordo con el proyecto.
  • Qué sucede si no se hace: Mejor caso : ha logrado pensar y evitar todos los riesgos por su cuenta. Sin embargo, es más probable que no hayas pensado en todo y que habrá cosas importantes que te habrás perdido. Los casos típicos de los problemas aquí incluyen transferencia y manejo inmanejables de archivos de almacenamiento cuando el modelo se mueve a producción. El resultado del modelo pierde la marca y no está en la forma más útil. Este fue el caso con uno de los modelos que produje. Escribí un código que hacía múltiples llamadas a la API, muchas de las cuales eran innecesarias. Estuvo bien en un pequeño conjunto de datos que ejecuté localmente, pero los servidores tuvieron problemas con la carga en producción. No se solucionó hasta que hablé con un ingeniero que me ayudó a diagnosticar el problema.

4. Model Development

  • ¿Por qué hacerlo? Este es el modelo que usamos para resolver el problema en última instancia.
  • ¿Qué implica? La diferencia radica en lo que está involucrado. No se trata solo de crear un modelo. Hay innumerables artículos sobre cómo escribir algoritmos de aprendizaje automático para resolver problemas específicos, así que no explicaré esto aquí. En cambio, es importante hacer hincapié en algunos pasos que deben llevarse a cabo para producir código de producción de alta calidad. En el proceso de desarrollo debería realizar revisiones de código regularmente. Recuerde que es probable que usted no sea el único que ve el código y, usted no es el único que invierte en el proyecto de éxito, por lo que debe haber una buena documentación del código . Esto es vital para la longevidad del proyecto. Es casi seguro que habrá errores y aportes inesperados en la producción, por lo que puede mitigar estos problemas realizando pruebas de código para mejorar la solidez del código. Esto incluye pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación del usuario (UAT). Los detalles sobre cómo hacer que su código pueda producirse pueden variar de un equipo a otro, pero otras cosas que lo ayudarán son: trabajar en un entorno aislado (entornos virtuales o contenedores Docker), usar el registro para escribir archivos de registro, usar archivos de configuración para que el la configuración está separada del código principal.
  • ¿Cuál es el resultado de esta fase? Un depósito compartido (Github) con los archivos necesarios y un modelo de trabajo que resuelve el problema definido en el proyecto.
  • ¿Qué sucede si no se hace? El modelo debe completarse; de ​​lo contrario, el problema no habrá sido resuelto Si no se prueba su código, habrá errores con la lógica que pueden no notarse hasta la producción. Si el código no es revisado por otra persona o no está documentado, será difícil para otras personas asumir el control cuando inevitablemente abandone la compañía o esté de vacaciones anuales. Algunos de estos problemas aparecerían consistentemente en proyectos que había hecho anteriormente que no eran sólidos. Aún estaba corrigiendo errores en un proyecto en el que estuve involucrado nueve meses después de que se “completó” porque el código no era sólido. Esto consume tiempo que podría estar usando para hacer otras cosas valiosas y causa mucha frustración para todos los involucrados. Asegúrese de pasar el tiempo adicional requerido para que el código sea robusto durante el período de desarrollo, ya que le ahorrará tiempo a largo plazo.
  • Recursos Hay muchas cargas, pero estas son algunas de las que He leído que realmente me gusta:
  • En la parte superior de la lista hay un artículo llamado “ Cómo escribir un código de nivel de producción en Data Science? ” Cubre prácticamente todo lo que puedo pensar Si eres un data science que construye código de nivel de producción, entonces deberías leerlo.
  • Revisiones de códigos: Código revisando trabajos de ciencias de datos y Un artículo sobre cómo ‘hacer revisiones de código por ti mismo’ es decir, escribir de manera tal que sirva para ser revisado (esto no sustituye la realización de revisiones de código reales, solo está aquí para ayudarlo a pensar sobre cómo escribir un buen código)
  • Documentación de código: una buena guía en cómo documentar el código correctamente . También me gusta docstrings de estilo numpy
  • Prueba de código: una guía sobre cómo escribir pruebas de unidad para el código de aprendizaje automático . Esta es una buena guía para escribir pruebas unitarias usando Python’s Pytest library . Usé esto para ayudarme a escribir mi primer conjunto de pruebas para uno de mis proyectos. La misma compañía también tiene un artículo sobre datos de burla para las pruebas . Y aquí hay otra guía sobre Pytest y burla

5. Seguimiento y retroalimentación del modelo

  • ¿Por qué hacerlo? Esto es para asegurar que nuestro producto esté funcionando como se pretendía en la producción. Las salidas de la solución deben ser estables y confiables. Deberíamos ser los primeros en saber si algo está mal. ¿El rendimiento del modelo es más bajo de lo esperado? ¿Los datos están formateados de forma diferente a los datos de entrenamiento? ¿Son los datos incorrectos? Esto nos ahorra mucho tiempo verificando manualmente los resultados y pasando por el código para garantizar que todo funcione como se espera. Este es especialmente el caso cuando las partes interesadas comienzan a cuestionar nuestros datos. Estamos en el negocio de proporcionar valor a la empresa, por lo que también deberíamos medir el impacto que tienen nuestras soluciones. ¿Está funcionando? ¿Necesita ajustes? ¿Cuánto dinero estamos generando? ¿Con qué frecuencia se utiliza la solución? Estos son los números que podemos informar a los ejecutivos para mostrar el valor que la ciencia de datos está aportando al negocio.
  • ¿Qué implica? Esto implica un período de tiempo (quizás un par de semanas) después de que el modelo se haya puesto en producción para verificar de forma manual y proactiva que todo está funcionando. Esto también implica automatizar el proceso de supervisión. quizás creando un panel de control y alertas automáticas por correo electrónico y / o un sistema de detección de anomalías. Quizás las partes interesadas también necesiten monitorear, por lo que es posible que la solución de monitoreo deba ajustarse para que sea fácil de usar para los colegas no técnicos. A los fines de la retroalimentación, esto puede implicar debatir con el interesado cómo recibirá los comentarios. ¿Será cualitativo o cuantitativo? Podría escribir algo en el producto que registra el uso para que no tenga que preguntar explícitamente al actor sobre sus hábitos de uso.
  • ¿Cuál es el resultado de esta fase? Métodos y productos para garantizar que el modelo funcione correctamente y que proporcione información cualitativa o cuantitativa sobre el uso y el valor de la solución. También puede incluir algún tipo de notificación / alerta si algo sale mal.
  • ¿Qué sucede si no se hace? Si nuestros productos no son monitoreados adecuadamente, potencialmente nos arriesgamos a que las partes interesadas pierdan confianza en las cosas que producimos cuando se rompen También podría costarle dinero al negocio y a nuestro equipo mucho tiempo tratando de arreglarlo. Un ejemplo de esto que he enfrentado es cuando los datos en la herramienta de análisis que construimos comenzaron a dar cifras increíblemente incorrectas. Resulta que el proveedor de los datos en bruto se había echado a perder. Pero, lo que es más importante, fueron nuestros grupos de interés los que se dieron cuenta del problema antes de que lo hiciera nuestro equipo de datos. Las pruebas robustas (como se describe en el paso de desarrollo del modelo anterior) y las alertas automáticas deberían haber recogido esto, pero no teníamos eso en su lugar. Cuando los datos finalmente regresaron, las partes interesadas pensaron que los datos seguían siendo incorrectos. ¡Nuestro equipo de datos pasó 2 semanas comprobando los datos solo para concluir que no había nada de malo en ello! Eso es 2 semanas que perdimos proporcionar valor al negocio. ¡La monitorización automatizada podría haberse reducido de 2 semanas a 2 minutos! Además, si no recibimos comentarios, entonces no tenemos idea de cuán útiles son nuestros proyectos o si todavía se están utilizando. Un ejemplo fue en una reunión con el equipo de marketing y tuvimos que hacer la pregunta “ ¿estás usando el modelo? “. Nunca deberíamos tener que hacer esa pregunta porque 1) deberíamos haber analizado el proyecto correctamente durante los pasos 1 y 2 para conocer el valor y estamos seguros de que nuestro modelo mejora con el modelo actual de solución / línea base 2) Deberíamos haber realizó el monitoreo como parte del proyecto, no en una reunión no relacionada. Esto muestra que no estábamos midiendo el impacto que están teniendo nuestros modelos.

Omisiones notables

Un buen amigo mío ( Michael Barber ) mencionó que me había perdido un paso importante: evaluación . La evaluación del modelo es una parte increíblemente importante del proceso y, si no se realiza correctamente, puede provocar una degradación inesperada de un modelo en producción. Aquí hay un excelente artículo sobre el uso de conjuntos de tren, prueba y validación adecuados para la evaluación del modelo.

Además, he perdido completamente la experimentación. Una de las mejores maneras de determinar si su solución de ciencia de datos ha tenido el impacto deseado es ejecutar un experimento y llevar a cabo una prueba A / B. Aquí hay un excelente artículo sobre A / B en Stack Overflow por Julia Silge .

No voy a entrar en detalles sobre estos porque esta publicación ya es demasiado larga y estos las cosas deberían plantearse en las primeras discusiones con las partes interesadas acerca de cómo el proyecto va a agregar valor al negocio (Vea el paso 3 sobre tener una discusión con las personas relevantes antes de completar un proyecto 😂. Tal vez habría incluido estos puntos primero tiempo).

Así que ahí lo tenemos. Estos son 5 pasos de alto nivel que creo que se requieren para desarrollar un proyecto de ciencia de datos exitoso. Debo señalar que no todos los pasos deben ser completados por un data science ya que algunos equipos pueden tener miembros dedicados para hacer algunas de las tareas. Por ejemplo, un analista de negocios o gerente de producto puede ser la persona que se pondrá en contacto con las partes interesadas para determinar si un proyecto es valioso y cuáles son sus requisitos. También puede haber algunos pasos que no son necesarios para todos los proyectos. Si un proyecto es una pieza de análisis de una sola vez, entonces no hay necesidad de crear un tablero para monitorear continuamente la salida.

Realísticamente, no es necesario que siga todos estos pasos para crear un proyecto de ciencia de datos exitoso. En la mayoría de los casos, no será práctico escribir todo un conjunto de pruebas y documentación, además de configurar un panel de control para un interesado con alertas automáticas cuando surjan anomalías. Es más probable que tenga que sopesar cuáles de estas cosas valen la pena para que pueda completar un proyecto según la fecha límite (probablemente poco razonable) que se haya establecido. Confieso que nunca he completado todos los pasos para un proyecto en particular, sin embargo, he sido consciente de lo que no estoy haciendo y por qué no hacerlo en este momento particular es una decisión pragmática.

La otra cosa importante que quiero destacar es que estos pasos son solo pautas para ayudar a que un proyecto tenga éxito. Pero para convertirse en data science exitoso hay otros rasgos que debe poseer y habilidades que deben aprenderse.

Soy muy consciente de que No soy el data science más experimentado y no sé lo que no sé, así que si alguien tiene algún comentario, pregunta o sugerencia, por favor siéntase libre de disparar en los comentarios. Gracias por leer:)


Cómo construir valiosos proyectos de ciencia de datos en el mundo real se publicó originalmente en Towards Data Science en Medium, donde las personas continúan la conversación resaltando y respondiendo a esta historia.

Loading Facebook Comments ...

Add a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Contacto
El mensaje ha sido correctamente enviado!



10 + 2 =