Hugo: Ben, bienvenido a DataFramed.
Ben: Gracias, Hugo. Encantado de estar aquí y con muchas ganas de hablar hoy contigo sobre Convoy y ciencia de datos.
Hugo: Totalmente de acuerdo. Es un placer tenerte aquí y, en nuestra exploración continua en DataFramed de qué es y qué puede ser la ciencia de datos, me hace mucha ilusión hablar hoy contigo sobre tu trabajo en Convoy y el papel que puede jugar la ciencia de datos para revolucionar el sector del transporte por carretera, probablemente uno de los más influyentes de Norteamérica. Pero antes, hablemos de ti.
Ben: De acuerdo, gracias.
¿Qué es un data scientist?
Hugo: Siempre me preguntan: ¿qué hacen realmente los data scientists? Ben, ¿qué creen tus compañeros que haces tú?
Ben: Es una gran pregunta. Creo que el término "data scientist" es bastante vago. Significa cosas distintas para personas distintas. Yo llego a la ciencia de datos con base en ciencias naturales y sociales. También hice una parada en Silicon Valley antes de hacer el doctorado en economía. Así que, en mi día a día, me paso como media jornada en reuniones hablando de la ciencia que hay detrás de cómo gestionamos nuestra plataforma, de cómo desarrollamos nuestro enfoque de ciencia de datos aquí, o de cuestiones concretas como el diseño de experimentos. Otra media jornada la dedico a mentorizar a otros data scientists, por ejemplo, ayudando a una persona junior a diseñar un experimento para una campaña o a construir un modelo de supervivencia para entender la retención de clientes.
Luego paso otra media jornada como contribuidor individual pensando en los factores que impulsan nuestra plataforma e intentando tener impacto apagando el fuego más urgente. Cosas como subastas, matching o pricing y ese tipo de problemas. Cualquiera que sepa matemáticas verá que eso suma tres mitades, pero trabajo en una startup y aquí las cuentas no siempre dan uno.
Hugo: No podría estar más de acuerdo. En DataCamp, a veces siento que funciono como una suma infinita, de hecho. Y como vienes de la física, me dijiste que para los físicos solo hay tres números, ¿no?
Ben: Exacto. Cero, uno e infinito, y todo lo demás es cuestión de escala. Es el chiste de siempre.
La carrera de Ben en ciencia de datos
Hugo: Exacto. Entonces, ¿cómo entraste en ciencia de datos?
Ben: Buena pregunta. Siempre he trabajado con software, datos, matemáticas, estadística y modelos, y cuando DJ Patil acuñó el término y se hizo viral, alguien en marketing me reetiquetó como data scientist. Pero ya en la carrera escribía software para abordar preguntas científicas. Lo primero con sabor a ciencia de datos que hice fue programar para estudiar la relajación de cráteres con McKinnon, un gran científico planetario en Washington University; por aquella época el grupo Frankie estaba de moda allí y, como tratábamos relajación de cráteres, llamé a mi programa Frankie. Más recientemente, tras el doctorado, estaba en la University of Chicago y me fichó Amazon. Fue hacia 2012. Ahí diría que hice la transición de la academia a aplicar esas cosas en la industria.
Hugo: ¿Y ahora trabajas como data scientist en Convoy?
Ben: Eso es.
Convoy
Hugo: Cuéntame un poco qué hace Convoy, cuál es su misión.
Ben: Es un gran ejemplo de que es mucho más fácil que el software entre en una industria establecida que que una industria establecida integre software por sí misma. El sector del transporte de mercancías lleva mucho tiempo. En EE. UU. es un mercado enorme, en torno a 800.000 millones de dólares. Hay un problema: el lado de los carriers está muy fragmentado. Los carriers son las empresas de transporte, con uno o varios camiones, y en el percentil 95 tienen dos o tres camiones. Así que los shippers se conectan con ellos mediante brokers que operan con tecnología de los 80: teléfono y fax. En Convoy estamos abriendo camino con el "digital freight": usamos tecnología y, en particular, ciencia de datos para mejorar todo el proceso para todos, porque es clave emparejar el carrier adecuado con la carga adecuada del shipper; así todo funciona mejor. Hay que poner precio, hacer el matching y automatizar el proceso, y eso va a revolucionar la estructura de costes del sector. A quienes nos escucháis, además de oyentes sois consumidores: la mayoría de las cosas que compras hacen entre ocho y diez viajes en camión hasta llegar a ti. Si bajamos el coste del transporte, los precios deberían ser más competitivos en lo que compras.
Hugo: ¿Y cómo se ve esto en el día a día para…? Has dicho que los carriers son los conductores, ¿no?
Ben: Carriers… Es una definición algo compleja porque muchos son propietarios-operadores: el sueño americano. Por ejemplo, aquí en el Noroeste del Pacífico, puede ser un inmigrante ruso que llega sin nada y con esfuerzo se convierte en propietario de un camión y, a medida que le va mejor, amplía su flota. Eso es algo en lo que Convoy quiere ayudar a los propietarios-operadores. O puede ser una empresa de transporte mediana ya establecida. Suelen tener uno o más camiones. Es difícil que una persona escale más allá de unos 20 camiones porque la logística se complica y aparecen RR. HH., etc.
Hugo: Claro. ¿Y qué supone Convoy para los carriers sobre el terreno? ¿Usan apps o…?
Ben: Sí, buena pregunta. La principal interacción es a través de la app de Convoy. Tenemos un proceso de onboarding muy simple para que nos envíen su documentación: seguros, licencias… y activamos su cuenta. A partir de ahí ven ofertas según los tipos de cargas que les interesan. Por ejemplo, pueden decir: "Quiero operar por el corredor de la I-5". Aceptan cargas en la app sin hablar con nadie. Súper eficiente.
También pueden pujar por cargas. Si no les gusta nuestro precio o compiten con otros carriers por una carga, pueden pujar; el precio sube o baja según el mercado. Y otra cosa buena: si llevan una carga de San Francisco a Los Ángeles y lo vemos, les proponemos: "Tenemos una carga desde Los Ángeles de vuelta hacia donde estabas o a otro destino". Así intentamos que no paren de moverse y ganen dinero, reduciendo los trayectos en vacío, porque resulta que los camiones circulan vacíos alrededor del 40% del tiempo, lo cual es malo para el medioambiente y para los camioneros.
Hugo: Claro, me imagino que estáis resolviendo variaciones del problema del viajante: no quieres que un conductor haga un Seattle–Bay Area en vacío para luego cargar allí. Quieres optimizar el viaje con respecto a lo que transporta, ¿no?
Ben: Exacto. Cuanta más liquidez hay en la plataforma, más fácil es resolver estos problemas y mantener a los carriers prácticamente en movimiento continuo.
Hugo: Muy interesante. Una de las razones por las que me atrae es que, cuando pensamos en el papel de la ciencia de datos en la industria moderna, solemos pensar en tech, nacida con el auge del acceso a datos. Tú, en cambio, hablas de revolucionar una industria anterior a toda esta infraestructura tecnológica.
Ben: Totalmente. Y si tenemos éxito, vamos a cambiar la estructura de costes de un sector clave que afecta a mucha gente en EE. UU. Un dato alucinante que aprendí en Convoy: el trabajo más común en algo así como 45 estados es el de conductor de camión. Afecta a mucha gente en su empleo y también a todos los consumidores. Puede tener un gran impacto positivo, especialmente para los conductores: les facilitamos gestionar y hacer crecer su negocio, con mucha menos fricción.
Ciencia de datos en Convoy
Hugo: Claro. Entonces, ¿cómo encaja la ciencia de datos en la misión de Convoy?
Ben: Es central. Desde el primer día hemos sido una empresa automatizada. Tenemos que resolver un montón de problemas fascinantes con mucha economía de por medio. Es clave predecir precios: debemos fijar bien el precio a los shippers —a menudo firmamos contratos a largo plazo— y también a los carriers. Luego hay que resolver el matching, asignar el carrier adecuado a la carga adecuada, porque así el resultado es mejor para todos. Por ejemplo, "adecuado" puede significar menos deadhead, el tramo que recorres en vacío hasta el inicio de la carga, y también importan los puntos de destino. Nos preocupan las subastas y todo el mecanismo de aceptación de precio por parte de los carriers, así como muchas otras cosas de su ciclo de vida, y que todo vaya bien una vez que el carrier recoge la carga. Hay una cantidad enorme de problemas así.
Hugo: Parece un negocio con el clásico problema del huevo y la gallina: para convencer a los shippers necesitas carriers, y para atraer carriers necesitas shippers.
Ben: Sí, es difícil para cualquier plataforma. Hay un gran artículo de Simon Rothman, uno de nuestros inversores de la serie A, donde dice que básicamente tienes que arrancar dos empresas a la vez: crear oferta y demanda en paralelo. Es complicado porque hay que mantener el equilibrio.
Por suerte, tenemos un equipo de ventas increíble, muy bueno generando demanda de calidad, y nosotros construimos oferta rápido para mantener el balance. Eso lo monitorizamos. Cualquier plataforma se preocupa por la liquidez y el equilibrio. Es como si entras a un sitio de citas hetero y no hay mujeres: mala experiencia. Necesitas equilibrio entre hombres y mujeres.
Hugo: Lo tengo presente porque en DataCamp, al principio, tuvimos un reto similar: conseguir estudiantes y, a la vez, instructores, porque los instructores quieren audiencia y los estudiantes quieren a los mejores, ¿verdad?
Ben: Tal cual. Y además están los efectos de red. Una vez arranca, el crecimiento suele ser exponencial. Es emocionante. Si lo haces bien, no duermes.
Hugo: Totalmente. Dijiste que uno de los factores clave es un equipo de ventas fuerte. ¿Cómo se integra el equipo de ciencia de datos con, por ejemplo, ventas?
Ben: Una de las cosas importantes que podemos hacer es ayudarles a entender pricing: cómo pujar por cargas, por cuáles merece la pena pujar… Ahí trabajamos muy de cerca. El pricing es increíblemente complejo y está lleno de incentivos. Llevaría horas desgranarlo.
Hugo: Hemos estado rodeando el papel de la ciencia de datos. ¿Qué preguntas concretas de ciencia de datos tienes que responder en tu trabajo?
Ben: Algo muy bueno de la cultura de Convoy es que somos realmente data-driven y hacemos muchísima experimentación, como supongo que todos los líderes del sector. Muchas preguntas las respondemos con experimentos: es la única forma. Hemos invertido fuerte en un framework de experimentación muy sólido que nos permite iterar rápido. Hay distintos enfoques para A/B testing, bayesiano o frecuentista; el bayesiano o el análisis secuencial te da respuesta más rápido y también facilita hablar de resultados con los product managers.
A/B testing
Hugo: Volvamos un paso y pon un ejemplo de test A/B que hagáis.
Ben: Genial. Lo típico es probar si un nuevo flujo de UX funciona mejor. Por ejemplo, nos importa que, cuando un conductor termina un viaje, suba automáticamente su documentación: el BOL, bill of lading. Si lanzamos un proceso nuevo para facilitarlo, podemos hacer un experimento dejando a la mitad de carriers con la tecnología antigua y a la otra mitad con la nueva y, tras un tiempo, decir con cierta probabilidad si el proceso nuevo funciona mejor.
Hugo: Gran ejemplo y gran descripción del A/B testing. Has mencionado que los métodos bayesianos convergen o te dan resultados más rápido que los frecuentistas. Te pongo en un aprieto, ¿podrías explicar brevemente a no especialistas la diferencia entre la estadística frecuentista, quizá más conocida, y la bayesiana que comentas aquí?
Ben: Por supuesto. El primer enfoque real a la estadística fue el bayesiano, desarrollado por Thomas Bayes, que era vicario. Su idea funciona como tu intuición: empiezas con unas creencias previas, por ejemplo, "mi proceso nuevo es mejor, generará un uplift del 10%". Con los datos, actualizas esas creencias. Ese updating bayesiano converge a lo que llamamos el posterior, la distribución esperada para ese uplift.
La visión frecuentista… Antes de seguir: los métodos bayesianos eran muy difíciles de computar hasta hace un par de décadas. No había recursos. Desde entonces han mejorado mucho y es más fácil calcular estos modelos; antes solo resolvías casos especiales. Gente como R. A. Fisher los criticó bastante y desarrollaron el enfoque frecuentista a principios del siglo XX. Ahí la idea es que existe un valor verdadero del parámetro y, con suficientes datos, converges a la verdad.
Los frecuentistas hablan de p-valores e intervalos de confianza: el contraste de hipótesis clásico. En ese mundo tendrías que decirle a un marketing manager: "Condicionado a que la hipótesis nula sea cierta, la probabilidad de observar un efecto tan grande o mayor que el visto es del 5,7%". Luego discutiríais si eso es significativo al 5%. En este caso no rechazarías la nula, pero tu manager podría decir: "5,7% está cerca del 5%, usemos 10%". Es un lío. Con el enfoque bayesiano puedes ir al product manager y decir: "Hay un 94,3% o un 98% de probabilidad de que la variante A sea mejor que la B". La conversación es mucho más fácil.
Hugo: En tu ejemplo de variantes A y B, el parámetro que miramos sería el porcentaje de personas que suben correctamente toda su documentación, ¿no?
Ben: Correcto.
Hugo: Como función del flujo de UX.
Ben: Eso es. Lo que estés probando: si el nuevo flujo tiene mayor click-through o mayor checkout, si reduce churn… Lo que te interese. El enfoque bayesiano facilita conversar con producto y, además… En nuestras simulaciones, converge más rápido. Para nuestro negocio. Tu experiencia puede variar; si estás en Europa, tus kilómetros pueden variar.
Hugo: Creo recordar que Dave Robinson escribió varios posts para Stack Overflow sobre A/B testing bayesiano y mostró que en sus experimentos no necesariamente convergía más rápido. Lo revisaré y lo pondremos en las notas.
Ben: Sí. Evan Miller también tiene posts muy buenos sobre el tema.
Otras técnicas y métodos: econometría y machine learning
Hugo: Mencionaste diseño experimental. Es interesante, porque mucha gente no espera que el diseño experimental tenga tanto peso al reinventar el transporte por carretera usando ciencia de datos. ¿Qué otras técnicas os interesan?
Ben: Antes de seguir, por cerrar A/B: en el sector del transporte hay mucha sabiduría práctica. Somos mitad startup tecnológica, mitad veteranos del transporte, con mucho conocimiento e intuición ganados a pulso, pero no siempre precisos. Con experimentos, concretamos.
Hugo: ¿Hay también algo político o social ahí? Mucha gente lleva años, con poder y conocimiento; llega una startup tech a "disrumpir" y hay que gestionar ese aspecto social, ¿no?
Ben: Solo puedo hablar de la cultura de Convoy: es muy de equipo. Como en un buen equipo de hockey. Ambos lados valoran lo que aportan. Incluso dos veteranos pueden no estar de acuerdo. En Convoy intentamos que, si un desacuerdo no se resuelve con teoría o datos, hacemos un experimento en vez de discutir sin fin.
Hugo: ¿Y qué más? ¿Qué otras metodologías usáis?
Ben: Somos muy de ciencia de datos aplicada y práctica. Resolvemos problemas de negocio concretos en poco tiempo. Usamos el toolkit estándar. Somos agnósticos de herramientas: R o Python, según convenga. En enfoques, a veces lo mejor es machine learning, especialmente si hay que predecir algo: si alguien subirá el BOL o si será un buen carrier. Ahí puedes montar una regresión logística o un clasificador boosting. Otras veces necesitas saber si A causó B y no puedes experimentar; vuelves al mundo de la estadística aplicada y haces regresiones. Mi primer "win" en Convoy fue que antes de que yo entrara lanzaron una funcionalidad sin A/B test y querían saber si ayudó. Usé el paquete CausalImpact de Google, con series temporales estructurales bayesianas, para mostrar que tuvo un impacto positivo.
Hugo: Fantástico. ¿Y con datos ya recogidos?
Ben: Sí. Tienes que intentar asegurar que todo sea lo más parecido posible a una asignación aleatoria. En un experimento necesitas asignación aleatoria al tratamiento y, además, cumplir cosas como individualidad, probabilística y no confusión. Si algo falla, vuelves al terreno observacional y usarás métodos de estadística aplicada o econometría para acercarte a algo "como si" fuera aleatorio y poder hacer inferencia causal.
Hugo: ¿Me recuerdas qué es la econometría?
Ben: Es el conjunto de herramientas estadísticas que han desarrollado los economistas para problemas económicos. En negocios son súper útiles porque la mayoría de problemas son de naturaleza económica. Un ejemplo clásico: selección muestral y otras formas de endogeneidad, donde los resultados se co-determinan en el modelo. Por ejemplo, entender si aumentar el número de policías reduce el crimen: el crimen depende de la policía, pero la policía también depende del nivel de crimen. Eso es simultaneidad. La selección muestral está por todas partes: quieres probar si clases pequeñas mejoran comprensión lectora, pero los padres con más recursos exigen clases pequeñas; ahora en esas clases hay niños, en promedio, más aventajados y sesgas el resultado.
Hugo: Y la econometría ha creado herramientas para afrontar estos retos.
Ben: Sí. En particular, hay un conjunto de herramientas muy conocido por economistas y menos por data scientists fuera de economía: los datos de panel. Sirven para lidiar con lo que llamaríamos heterogeneidad individual. Si observo el comportamiento de carriers o envíos, tienen rasgos propios no observables. Si puedo observar a un carrier en el tiempo, el panel me da métodos para eliminar esos efectos no observados que podrían sesgar las estimaciones.
Hugo: Interesante. ¿Dirías, si me equivoco corrígeme, que hay herramientas de econometría muy útiles que en ciencia de datos aún no se aprovechan lo suficiente?
Ben: Sí. Me encanta el machine learning, es genial, pero hay problemas donde no funciona y a veces se le presta tanta atención que se pasan por alto métodos econométricos que pueden resolver problemas que ML no puede. Hablé con alguien de Uber antes de ir a Convoy y me dijo que se toparon con problemas irresolubles con ML que solo pudieron abordar con un modelo econométrico estructural. Construirlo es complejo y lleva un año o más, modelas todo el proceso de decisión y la función de utilidad, pero al final tienes un modelo muy potente para predecir contrafactuales.
Hugo: Guay. ¿Y eso fue en Uber?
Ben: Sí. Salió durante mi entrevista allí, antes de ir a Convoy.
Datos geoespaciales, calidad y vehículos autónomos
Hugo: También parece que manejáis muchos datos geográficos, series temporales geoespaciales. ¿Juegan un papel en vuestro trabajo?
Ben: Sí. Son muy importantes y estamos empezando a exprimir su potencial. En la app los usamos mucho para mejorar la experiencia del carrier. Por ejemplo, cuando llega a recoger una carga, podemos hacer el check-in automático con datos geoespaciales. Algunas instalaciones de carga funcionan mal y, si hacen esperar al camión demasiado, deben pagar lo que se llama detention. Podemos pagar esa detention automáticamente cuando el carrier tiene derecho, en lugar de exigirle un proceso farragoso de documentación, parecido a tramitar un parte al seguro en EE. UU.
Hugo: Cuando dices que tenéis muchos datos cuyo potencial aún no habéis explorado, parece que también podría haber espacio para investigación social con esos datos.
Ben: Sí. Hay muchas preguntas interesantes sobre matching, plataformas y subastas que me encantaría explorar más a fondo. Seguro que se podrían escribir muchos artículos académicos.
Hugo: ¿Qué proyectos de ciencia de datos en Convoy te parecen más impactantes o reveladores para la sociedad?
Ben: Buena pregunta. Llevo algo más de un año en Convoy y la empresa tiene poco más de dos. Me he centrado sobre todo en pricing y experimentación. Uno de los experimentos más interesantes lo hicimos poco después de llegar: dimos acceso preferente a cargas a carriers de mayor calidad… y la calidad bajó. Todo el mundo se quedó a cuadros: "¿Cómo puede ser? Damos prioridad a los mejores y baja la calidad". Un mal manager diría: "Científico, te has equivocado". Pero tenemos un gran responsable de data science, Ziad Ismail, que ha construido una cultura de datos muy sana. Nos dejó investigar. Pensé en la literatura de matching en economía. Mi hipótesis fue que, al restringir el pool de carriers a un grupo más pequeño —aunque de mayor calidad—, la calidad del emparejamiento en cada trabajo bajaba. Lo verificamos y luego hicimos regresiones que mostraron que la calidad del matching impactaba causalmente en la calidad. Fue un hallazgo emocionante: el matching es clave en la plataforma.
Hugo: Increíble. A ver si lo entiendo: dar acceso temprano a cargas a carriers de alta calidad bajó la calidad del algoritmo de matching con los shippers y eso redujo la calidad del resultado.
Ben: Sí. La calidad de la ejecución del trabajo bajó porque el conjunto de elegibles era más pequeño y, aunque eran mejores, el hecho de tener menos posibles combinaciones pesó más que su mayor calidad.
Hugo: Hay una hormiga brasileña con un 30%… No es un análogo directo, pero en cada colonia hay un 30% que no hace nada; si las quitas, al día siguiente hay otro 30% inactivo. No digo que haya shippers o carriers que no hagan nada, pero parece haber fuerzas de equilibrio. Es muy interesante que ocurriera lo contrario a lo intuitivo.
Ben: Exacto. Por eso es tan importante experimentar. Aquí tenemos la tradición de que, antes de ver los resultados, la gente vota qué variante cree que ganará. Involucras a toda la empresa. El equipo de UX suele dar donuts o pegatinas a los ganadores. Hemos visto muchos casos en los que pasa lo contrario de lo esperado. Es fácil enamorarte de una funcionalidad que te parece increíble, pero cada vez cuesta más mover la aguja.
Hugo: En cierto modo, estáis ejecutando un laboratorio, ¿no?
Ben: Sí, enfocado a nuestras preguntas de negocio.
Hugo: Si esto entra en estrategia o material privado, me dices. ¿Cómo medís la calidad de los carriers o de una entrega?
Ben: Hay un problema general en el transporte: en torno a un 10% de las veces, cuando un carrier se ha comprometido con una carga, no aparece o te avisa en el último minuto de que no la hará. La excusa típica: "Se me ha averiado el camión". Los camiones no se averían un 10% del tiempo. Significa que alguien les ofreció una carga mejor pagada. Hay carriers que lo hacen a menudo y otros que, tras 100 o 300 viajes, prácticamente nunca fallan. La tasa de fall off es una métrica clave de calidad porque, cuando pasa, nos cuesta mucho dinero: estamos comprometidos a dar una experiencia excelente al shipper y tenemos que encontrar otro camión en el último minuto, lo cual es carísimo.
Hugo: Tiene sentido. ¿Y pensáis en la llegada de coches o camiones autónomos?
Ben: Sí. Antes, otras cosas que miramos sobre calidad…
Hugo: Sí, por favor.
Ben: La puntualidad del conductor; que usen la app es muy importante porque nos permite reducir costes en compliance y seguridad. Todo eso importa, pero en el experimento que mencioné, el fall off fue lo principal. Vemos que si logramos que usen la app, pasan muchas cosas buenas. Otra tarea de data science con mucho de economía es diseñar incentivos en la plataforma para fomentar el comportamiento deseado. Por ejemplo, si el carrier usa la app, tiene quick pay: le pagamos en el día. En el sector, lo normal es pagar en unos 30 días, así que suelen vender el derecho de cobro a una empresa de factoring y pierden otro 2-3%. En la práctica, si usan la app, les estamos subiendo el sueldo un 2-3%.
Hugo: Es un aumento y, además, tienen más liquidez.
Ben: Claro. No sé tú, pero cuando trabajo me gusta cobrar. Esperar 30 días no es agradable. Hay que comprar comida, pagar el alquiler y piezas para la bici.
Hugo: ¿Y sobre los camiones autónomos? ¿Lo estáis pensando activamente?
Ben: Sí, totalmente. Los fundadores están muy conectados con ese mundo. Al final, cuando lleguen los camiones autónomos —probablemente por fases, con distintos niveles de automatización—, seguirán necesitando conectarse con cargas, y nosotros tenemos una plataforma para ello. Nuestro objetivo es integrarlos en el lado de la oferta.
La naturaleza multidisciplinar de la ciencia de datos
Hugo: Hemos hablado del impacto de la ciencia de datos en el transporte con tu trabajo en Convoy y lo hemos abordado desde muchos ángulos. Está claro que confluyen muchas cosas, y tú, en particular, eres economista computacional, exfísico y fuiste research scientist en Amazon. ¿Cómo encaja todo eso en tu rol como data scientist?
Ben: Nunca sobran herramientas. Cuando era un joven físico, tuve la suerte de trabajar con John Wheeler, que, además de canalizar a Niels Bohr, decía: "Nunca cites nada hasta saber la respuesta". Es una Wheeler-ada famosa: debes tener un olfato de cuál es la respuesta razonable a tu problema científico. Feynman llegó un día convencido de haber demostrado algo y Wheeler le dijo que estaba equivocado. Feynman se molestó: ¿cómo podía Wheeler saberlo si él acababa de resolverlo? Había un error en el cálculo de Feynman. Wheeler sabía tanta física que intuía que no cuadraba. Traslada eso a datos: si mides un uplift del 10% en una campaña de correo directo, probablemente está mal. No esperarías eso. La física te ayuda a ser resolutivo y a fortalecer las mates, sobre todo álgebra lineal, que me parece crucial para tener éxito en ciencia de datos, quizá más que el cálculo. La economía me dio herramientas teóricas para pensar problemas de negocio y herramientas de econometría para contrastar teoría y datos. Mi etapa de ingeniería de software me dio habilidades para convertir estadística en código. En cada sitio aprendes habilidades nuevas. También en Amazon se aprende una forma muy adulta de pensar problemas: urgencia, foco en impacto. Es como un doctorado, donde te preguntas a menudo: "¿Lo que hago me acerca a terminar?"; si no, estás en lo incorrecto.
Hugo: Diste una charla estupenda en Data Science Pop-Up Seattle: Correctness in Data Science. Me gustó porque señalabas tipos de errores y cómo corregirlos para construir una disciplina bien definida, que ahora mismo es un conjunto algo difuso de técnicas, conceptos y aplicaciones. ¿Cuáles son los grandes errores que ves hoy?
Ben: Me alegra que te gustara.
Hugo: Me encantó, y la pondremos en las notas para que todos la vean.
Ben: Genial. La corrección de los modelos científicos es clave. Mucha gente, sobre todo al empezar, piensa: "Mi código se ejecutó, dio un número, debe estar bien". Calma. Asegúrate de que es el número correcto. Hay un marco epistemológico del sector nuclear llamado verificación, validación y cuantificación de la incertidumbre (VV&UQ). Se lo debo a Robert Rosner, mi supervisor de posdoc y exdirector de Argonne, por presentármelo. Son tres cosas: verificación es comprobar que tu código implementa bien el modelo, al margen de si el modelo es correcto. Haz unit tests, genera datos sintéticos por Monte Carlo con parámetros conocidos y comprueba que recuperas lo esperado. Validación es asegurar que el modelo es fiel a la realidad: ejecutar experimentos después y verificar que representa bien lo real. La cuantificación de incertidumbre trata de los límites del modelo: ¿qué supuestos has hecho? ¿Se cumplen? ¿Y si llega un tsunami y se lleva tu central? Igual conviene planificarlo. Me gusta preguntar a ingenieros de BI cómo saben que su SQL es correcto; me miran raro. Pero el SQL —o lo que uses para extraer datos— es crucial: si montas un dataset basura, nada lo arregla, ni la estadística más sofisticada. Hay que ser metódico al ensamblar datos: piensa en tus joins, prueba con subconjuntos, comprueba estadísticas agregadas y distribuciones. Cosas sensatas como no creerte un uplift del 10% en tu mailing. Y otra cosa: los modelos acaban en producción. Necesitarás tests de integración u otros para asegurar que lo de producción es fiel a lo desarrollado.
Ciencia de datos en producción
Hugo: En tus trabajos anteriores o en Convoy, ¿qué papel tiene el data scientist en llevar modelos a producción?
Ben: Depende mucho de la organización y del equipo. En algunos, el data scientist hace investigación y "pasa la pelota" a ingeniería, que hace magia. Eso puede ser problemático: se pierden cosas por el camino. A muchos ingenieros no les hace gracia que les pases código en R; con Python, mejor. En Convoy intentamos que los data scientists sean dueños end-to-end de sus modelos y que tengamos una plataforma de ML que permita desplegarlos. Aún nos queda camino, pero creo que es mejor para todos: los ingenieros llaman a un data service y obtienen el resultado que necesitan. Además, nuestra organización en grupos de producto ayuda mucho: un PM, uno o más data scientists y varios ingenieros. Y nuestros PM son muy técnicos: la mayoría tienen máster en informática o equivalente, un buen MBA, y todos escriben SQL. En una entrevista, le planteé a un PM una consulta con left outer join y la resolvió en 60 segundos. Creo que ya está cansado de que lo cuente, pero ese es el nivel. Técnicos, orientados a datos, entienden estadística de grado. Eso les hace defensores de hacer las cosas bien con datos. Y, además, fomentamos la conexión horizontal entre data scientists: brown bags, one-to-ones técnicos, etc., para desbloquear dudas y alinear dirección.
Hugo: Un PM técnico puede conversar contigo de tú a tú.
Ben: Sí. Están muy comprometidos con ser data-driven. Saben que, si escriben un plan para una nueva funcionalidad, deben trabajar con el data scientist para tener un plan de medición —tipo Stack Overflow plan u otro— para verificar y validar sus ideas. Son defensores del uso de datos. El listón para PMs es muy alto, pero es crucial que participen en la conversación de datos, porque a menudo impulsan preguntas de investigación. Un ejemplo del enfoque data-driven: Ziad Ismail, nuestro chief product officer, escribe SQL. Se queda hasta tarde escribiendo consultas para entender el negocio y conoce nuestro data warehouse tan bien como cualquiera.
Hugo: Genial. Tú, además, tienes una caja de herramientas muy potente en estadística, econometría y ciencia de datos. ¿Cuál es tu técnica o metodología favorita?
Ben: Buena pregunta; es como preguntar por tu pájaro o tu cámara favorita. En Reino Unido dirían: "¿Cuánto mide un trozo de cuerda?"
Hugo: Y nadie puede contestar eso.
Ben: ¿Verdad? Yo suelo…
Hugo: ¿Qué te interesa? ¿Qué te gusta?
Ben: …usar la mejor herramienta para cada caso. Vengo de un doctorado muy fuerte en métodos de datos de panel; en UCL, donde estudié, gente como Richard Blundell y otros impulsaron mucho ese campo. Así que es una de mis fortalezas. Pero también me gustan muchas herramientas de ML básicas. Depende del problema. Lo que más me gusta no es la herramienta, sino resolver problemas interesantes. Soy un científico aplicado. He trabajado desde cosmología cuántica hasta bioinformática y transporte, entre otras cosas. Tener problemas interesantes es lo que importa y saber encontrar la herramienta adecuada para resolverlos, también. Además de la herramienta, están los datos y el software.
El futuro de la ciencia de datos
Hugo: Hemos hablado mucho de la ciencia de datos actual. ¿Cómo ves su futuro?
Ben: Vivimos un momento increíble. Si tienes habilidades en mates y estadística, hay datos explotando por todas partes. Nos lo vamos a pasar muy bien… hasta que Elon Musk encuentre la forma de dejarnos sin trabajo.
Hugo: ¿Y hasta entonces?
Ben: Llegarán herramientas que automaticen muchos modelos sencillos. Ya se ven empresas vendiendo modelos de churn "commodity" y cosas así, lo que puede ser problemático porque cada empresa tiene datos únicos y te conviene construir tu propio modelo de churn. Pero verás más modelos commoditizados y herramientas que automaticen el fruto más bajo del árbol de data science. Para tener una carrera feliz y segura, sube en la cadena de valor, hacia tareas que no se puedan sustituir por automatización, como la ingeniería de características automatizada. En una empresa anterior, Context Relevant, avanzaron bastante en automatizar feature engineering para muchas clases de problemas.
Hugo: ¿Qué habilidades recomendarías desarrollar para no ser automatizado?
Ben: Nunca sabes demasiadas matemáticas. Vale la pena invertir ahí desde joven. Cuando enseñaba en Galvanize (un bootcamp de data science), podía remediar la falta de programación en ocho semanas. La falta de matemáticas, no: eso son años. Invierte continuamente en mates. Después, domina los algoritmos básicos y sigue leyendo. Mucha gente deja de leer al entrar en la industria. Para perfiles más avanzados, elige una especialización que te interese. A mí me atraen la experimentación y los métodos bayesianos, y he profundizado mucho en ambos estos años. Mucha gente se va a deep learning; es un espacio muy competitivo. Hay otras áreas igual de interesantes e importantes. Si quieres ir a deep learning, perfecto. Pero también hay valor en ser algo contrarian.
Llamada a la acción
Hugo: Estoy de acuerdo. Con todo esto, ¿tienes una llamada a la acción final para data scientists, novatos y veteranos?
Ben: Si te interesa entrar en ciencia de datos, entiende que te apuntas a una vida de aprendizaje y que esto es una maratón, no un sprint. Como un doctorado: hay que dosificarse. Puede llevarte años. Invierte: quizá veas un poco menos de Netflix por la noche y dediques más tiempo a leer libros y papers relevantes, a escribir código, a jugar con modelos. Y si no te entusiasman los datos, quizá haya otro sitio donde estés más feliz.
Hugo: Así que sigue aprendiendo, leyendo y haciendo.
Ben: Sí. Para mí, y para muchos en la profesión, los datos son como una novela de Agatha Christie: hay un misterio y quiero desentrañarlo y saber si fue el coronel Mostaza en el salón con el candelabro.
Hugo: Fantástico, Ben. Vives la ciencia de datos como una novela policíaca.
Ben: Algo así.
Hugo: Puedo identificarme: los datos no paran de hablar. Un colega siempre dice que hay que escuchar a los datos: te hablarán si prestas atención.
Ben: Exacto. Y sobre los errores que comentabas antes: un error común es lanzarse a modelar demasiado pronto sin hacer EDA, el término de Tukey para análisis exploratorio. Merece la pena invertir tiempo en EDA: descubrirás sorpresas. Cuando me uní a Convoy y empecé a explorar, encontré problemas de limpieza y outliers sin tratar; los arreglamos y mejoramos un 10% el modelo de pricing. Rendimiento gratis.
Hugo: Muy revelador. Hacer EDA, porque es tentador saltar a modelar, pero siempre animo a visualizar los datos de 100 formas, mirar estadísticas descriptivas, etc., antes de nada.
Ben: Tal cual. Intento enseñar un enfoque metódico y estandarizado. Por eso me gusta CRISP-DM (el proceso estándar para data mining), que es probablemente el mejor flujo de trabajo para un proyecto de ciencia de datos: recorrer todos los pasos para no dejarte nada. Empiezas entendiendo el problema de negocio, luego qué datos tienes. Preparas datos. Modelas, evalúas y despliegas. En cualquier punto puedes descubrir algo que te haga volver atrás: modelas y te das cuenta de que no hiciste bien el feature engineering o necesitas una característica clave donde el modelo falla. Ser sistemático evita duplicar esfuerzos o saltarte pasos. Y, en cuanto a corrección, me gustaría combinar CRISP-DM con VV&UQ: así tienes un marco potente, profesional y maduro.
Hugo: Fantástico. Eso apunta a una estructura sistemática para lo que podría ser la ciencia de datos del futuro.
Ben: Sí. Y recuerda: modelar es la parte divertida, pero lo anterior es crucial y consume el 80% del tiempo: limpiar y preparar datos. Luego el modelado es rápido, un subidón, y pum, se acabó y vuelves a lo normal. Veremos más herramientas para acelerar esa fase previa, donde están las grandes ganancias de productividad. Invierte ahí: aprende UNIX, domina las herramientas de línea de comandos y otras tecnologías o plataformas que te ayuden a tener los datos listos para modelar más rápido.
Hugo: Exacto. Ben, ha sido un placer tenerte en el programa.
Ben: Gracias, Hugo. Un placer estar aquí y te deseo lo mejor con el programa.
Hugo: Gracias.
