LinkedIn se ha convertido en la principal plataforma profesional para científicos de datos, un lugar donde la credibilidad técnica se traduce directamente en oportunidades de carrera y en la confianza de los clientes.
A diferencia de GitHub o Kaggle, LinkedIn premia la capacidad de explicar ideas complejas en lenguaje sencillo.
El científico de datos que sabe explicar el impacto de negocio de un modelo le gana, una y otra vez, a quien solo les habla a otros especialistas.
Las publicaciones que mejor funcionan para científicos de datos siguen un patrón simple: cuenta lo que construiste, lo que se rompió o lo que te sorprendió.
Las historias reales rinden más que los tutoriales.
Una publicación sobre el modelo que falló en producción y cómo diagnosticaste el problema genera diez veces más interacción que una lista genérica de consejos, porque demuestra experiencia real y no conocimiento de manual.
Publicar con constancia durante tres a seis meses suele producir un efecto acumulativo: mejora la calidad de los reclutadores que te escriben, llegan invitaciones para dar charlas en conferencias y las consultas de empresas que enfrentan los problemas sobre los que has escrito se vuelven algo habitual.
La meta no es volverte viral.
Es convertirte en el experto reconocible que tus futuros clientes y empleadores buscan antes que a nadie más.
- 1
Mi modelo tenía un 94% de exactitud y era completamente inútil
Una historia personal sobre optimizar la métrica equivocada o resolver un problema que nadie tenía. La brecha entre exactitud e impacto es la gran ironía de la ciencia de datos, y confesarla genera credibilidad al instante.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Mi modelo tenía un 94% de exactitud. Era completamente inútil. Esta es la brecha de la que nadie me advirtió al inicio de mi carrera.
Había optimizado la exactitud en un dataset donde el 92% de las etiquetas pertenecía a la clase mayoritaria. Un modelo que siempre predijera la clase mayoritaria habría sacado un 92%: mi modelo 'impresionante' apenas era mejor que no hacer nada.
Peor aún, la mejora del 2% que sí ofrecía ni siquiera estaba en los casos que le importaban al negocio. Acertaba en la mayoría fácil y seguía siendo débil en la clase minoritaria, poco frecuente y de alto riesgo, que era la que importaba para la decisión real.
Ahora pregunto qué métrica corresponde a la decisión real antes de tocar un modelo. Una buena exactitud sobre el objetivo equivocado es solo una forma cara de equivocarse con total seguridad.
- 2
La mayoría de las empresas necesita un analista de SQL, no un científico de datos
Una postura a contracorriente sobre la inflación de cargos y el machine learning prematuro. Gerentes de contratación, analistas y doctores subutilizados van a llenar los comentarios con su propia evidencia.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
La mayoría de las empresas que contratan a un científico de datos en realidad necesitan un analista de SQL. Lo he visto pasar en dos empresas donde trabajé, incluida mi propia contratación.
Me contrataron para 'construir modelos de machine learning'. Mis primeros seis meses fueron solo dashboards, consultas de SQL ad hoc y responder pedidos del tipo 'sácame los números de X' de personas que de verdad solo necesitaban una consulta, no un modelo.
Ese trabajo no tiene nada de malo. Es valioso y muchas veces más útil de inmediato para una empresa que un modelo. El problema es el desajuste del cargo: contratar para machine learning cuando la necesidad real es analítica genera frustración en ambos lados, e inversión prematura en modelos cuando una consulta simple respondería la pregunta.
Antes de construir un modelo, pregunta qué decisión cambiaría realmente.
- 3
Cómo le explico un modelo a la dirección sin decir 'algoritmo'
Una guía práctica sobre traducción: analogías, costo de los errores en dinero y cómo presentar el nivel de confianza. La comunicación es la debilidad declarada del campo, así que las guías prácticas se devoran.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Cómo le explico un modelo a la dirección sin decir nunca la palabra 'algoritmo'.
Empiezo por la decisión que cambia, no por el mecanismo: 'esto marca el 8% de las cuentas con más probabilidad de cancelar el próximo mes, para que el equipo de retención las llame primero'.
Presento el costo de los errores en dinero, no en precision o recall: 'cuando nos equivocamos, nos cuesta una llamada de retención desperdiciada o un cliente que no salvamos; esto es más o menos lo que cuesta cada caso'.
Presento la confianza como un rango, no como una falsa certeza: 'esto no es una garantía, es un ranking, y mejora a medida que juntamos más datos'.
Sin jerga, sin nombres de algoritmos. La dirección no necesita entender el modelo. Necesita confiar en la decisión que respalda.
- 4
Le hicimos un A/B test al A/B test: nuestro tamaño de muestra era una fantasía
Una publicación de datos sobre análisis de potencia, el vicio de mirar resultados antes de tiempo y los experimentos que tu empresa dio por significativos. El contenido de rigor estadístico gana el respeto de los colegas y un pánico silencioso en los equipos de producto.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Le hicimos un A/B test al A/B test. Nuestro tamaño de muestra era una fantasía, y descubrirlo fue una lección de humildad.
Dábamos resultados por 'significativos' revisando los p-valores a diario a medida que llegaban los datos. El clásico peeking, que infla la tasa de falsos positivos muy por encima del 5% con el que todos creen estar trabajando.
Hicimos un análisis de potencia como se debe, en retrospectiva, sobre nuestras últimas seis pruebas 'ganadoras': tres no tenían suficiente tráfico para detectar el tamaño de efecto que decíamos haber encontrado. En la práctica, estábamos leyendo ruido como si fuera señal.
Ahora registramos el tamaño de muestra y una duración fija antes de lanzar cada prueba, y nadie mira los resultados hasta el punto final calculado.
Fue una conversación incómoda con producto por los ciclos de prueba más lentos. Mucho mejor que seguir tomando decisiones basadas en ficción estadística.
- 5
La stakeholder que pidió un dashboard pero necesitaba una decisión
Una anécdota sobre escarbar debajo de una solicitud para encontrar la pregunta real. Las historias de arqueología de requisitos conectan con todo científico de datos que se ahoga en tickets de dashboards.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Una stakeholder pidió un dashboard. Lo que realmente necesitaba era que le resolvieran una decisión, y construir el dashboard habría desperdiciado tres semanas.
Antes de construir nada, le pregunté qué haría distinto según los números. Resultó que la pregunta real era simple: ¿mantenemos o eliminamos un canal de marketing específico que rendía poco? Eso es un análisis y una recomendación, no un dashboard permanente que nadie revisaría después del primer mes.
En su lugar armé un análisis de dos páginas: el ROI real del canal, una recomendación clara y el intervalo de confianza alrededor. Entregado en cuatro días en lugar de tres semanas.
La mayoría de las solicitudes de dashboards son en realidad solicitudes de decisiones disfrazadas de dashboard. Preguntar qué haría distinto la otra persona antes de construir algo le ahorra tiempo real a todo el mundo.
Cuenta gratis
Crea tu cuenta gratis
ThoughtMint convierte lo que sabes en publicaciones de LinkedIn que suenan a ti. Por ahora la aplicación está en inglés: puedes usarla desde hoy y te avisaremos por correo cuando llegue la versión en español.
Prueba gratis: 7 días o 2500 palabras de IA, lo que ocurra primero. Sin tarjeta de crédito.
- 6
Cuatro errores de feature engineering que filtraron el futuro a mis modelos
Fuga del objetivo, variables posteriores al evento, contaminación entre entrenamiento y prueba. Confesar fugas de datos es el trauma compartido del campo, y los ejemplos concretos enseñan más que las advertencias de manual.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Cuatro errores de feature engineering que filtraron el futuro a mis modelos antes de que aprendiera a detectarlos.
Usar las 'compras totales históricas' de un cliente como variable para predecir la cancelación. En un pipeline ingenuo, ese total incluye compras hechas después de la fecha de predicción y le dice la respuesta al modelo en silencio.
Calcular un promedio móvil sobre una ventana que incluía el día exacto que se estaba prediciendo, no solo los días anteriores.
Dividir entrenamiento y prueba al azar en datos de series de tiempo, dejando que el modelo aprendiera patrones del futuro para predecir el pasado.
Hacer un join con una tabla que se actualizaba de forma retroactiva, así que 'lo que sabíamos al momento de predecir' se convirtió sin avisar en 'lo que sabemos ahora'.
Cada uno de estos errores produjo métricas de validación sospechosamente buenas. Mirando atrás, esa calidad sospechosa fue la pista todas y cada una de las veces.
- 7
Los LLMs se comieron mi pipeline de NLP. Esto es lo que hago ahora
Una reacción a la tendencia sobre cómo los modelos fundacionales reemplazaron a los clasificadores de texto hechos a medida, y dónde los métodos clásicos todavía ganan en costo y latencia. Relevante para la carrera y fácil de discutir.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Los LLMs se comieron mi pipeline de NLP hecho a medida. Esto es lo que hago ahora, en concreto.
Antes construía y mantenía clasificadores de texto propios para detección de intención, sentimiento y extracción de entidades. Infraestructura real, ciclos de reentrenamiento reales, una carga real de mantenimiento.
Hoy, para la mayoría de esas tareas, un modelo fundacional con un buen prompt y un puñado de ejemplos iguala o supera la exactitud de mis viejos clasificadores, y lo armo en una tarde en lugar de semanas.
Dónde los métodos clásicos todavía ganan para mí: en clasificación de altísimo volumen, baja latencia y sensible al costo, donde una llamada a un LLM es simplemente demasiado lenta o cara a escala, y en cualquier cosa que necesite lógica totalmente determinista y auditable.
Mi trabajo pasó de entrenar modelos a evaluarlos y darles instrucciones. Una habilidad distinta, con un criterio de fondo parecido sobre lo que los datos realmente necesitan.
- 8
Una semana en mi trabajo real: 70% fontanería, 10% modelado
Una auditoría de tiempo detrás de escena que derriba la fantasía de Kaggle. Los desgloses honestos de carga de trabajo los comparten los seniors para recalibrar a los juniors, y los juniors con algo de desesperación.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Una semana en mi trabajo real, registrada con honestidad: más o menos 70% fontanería de datos, 10% modelado y el resto repartido entre reuniones y comunicar resultados.
Lunes: tres horas limpiando un dataset con formatos de fecha inconsistentes entre dos sistemas fuente que en teoría tenían los mismos datos.
Martes y miércoles: construir y depurar un pipeline de datos, sin tocar un modelo ni una vez.
Jueves: por fin, modelado. Unas cuatro horas de trabajo real con el modelo, la parte que cada competencia de Kaggle te entrena para creer que es todo el trabajo.
Viernes: presentar resultados, medio día, traduciendo hallazgos a un lenguaje con el que un VP pudiera actuar.
En la universidad nadie te advierte que el modelado estilo Kaggle es quizás un 10 a 15% del trabajo real. El resto es igual de importante y mucho menos glamoroso.
- 9
Seis preguntas que me hago antes de empezar cualquier proyecto de modelado
Una lista sobre verificar un baseline, el impacto en la decisión, la disponibilidad de datos y la opción de no hacer nada. Los marcos para filtrar proyectos los guardan los líderes que se ganan la vida matando proyectos malos.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
Seis preguntas que me hago antes de empezar cualquier proyecto de modelado, porque la mayor parte del valor está en decidir qué no construir.
- ¿Hay un baseline o una heurística simple que no hayamos probado primero?
- ¿Qué decisión concreta cambia según el resultado de este modelo?
- ¿De verdad tenemos los datos, con el volumen y la calidad necesarios, o estamos suponiendo que los tendremos?
- ¿Qué pasa si no hacemos nada? ¿Cuál es el costo de dejar las cosas como están?
- ¿Quién es responsable de actuar con el resultado del modelo una vez que exista?
- ¿Cómo vamos a saber si el proyecto fracasó, y cuándo lo damos por cerrado?
La mitad de los proyectos de modelado que he matado con estas preguntas murieron en la primera conversación, antes de que alguien escribiera una línea de código.
- 10
¿Cuál es la métrica más sobrevalorada en ciencia de datos hoy?
Una pregunta de interacción que invita a nominar desde la exactitud hasta el R cuadrado o los usuarios activos mensuales. Las quejas sobre métricas son universales en este campo y generan hilos de comentarios inusualmente sustanciosos.
Ejemplo de publicaciónEjemplo ilustrativo: adapta la estructura, pero no presentes estos nombres, cifras, empresas o situaciones como propios.
¿Cuál es la métrica más sobrevalorada en ciencia de datos hoy? Nomino la mía y asumo las críticas.
La exactitud, sola, sin mencionar el balance de clases ni el costo real de los distintos tipos de error. La he visto citada en reuniones de directorio como si un solo número pudiera resumir el valor real de un modelo, cuando a la decisión que respalda casi siempre le importa mucho más un tipo de error específico que la tasa agregada.
Muy cerca en segundo lugar: el R cuadrado, tratado como una señal universal de calidad cuando casi no dice nada sobre si el modelo sirve para la tarea de predicción concreta.
¿Cuál es la tuya? Quiero la métrica que hayas visto mal usada en una reunión y lo que realmente se debió reportar en su lugar.
Preguntas frecuentes
¿Qué debe publicar un científico de datos en LinkedIn?
Publica sobre impacto y traducción, no solo sobre técnica. Las historias donde un análisis cambió una decisión de negocio, los experimentos que sorprendieron a los stakeholders y los relatos honestos de modelos fallidos rinden más que los tutoriales de métodos, que ya sobran.
Lo visual ayuda muchísimo: un solo gráfico con una conclusión clara es el formato de ciencia de datos que mejor funciona. Escribe para la persona inteligente que no es especialista; es quien te asciende y te contrata.
¿Con qué frecuencia debe publicar un científico de datos en LinkedIn?
Dos publicaciones por semana es una buena meta. Una rotación confiable: un hallazgo o gráfico de tu trabajo (anonimizado) y una opinión sobre métodos, herramientas o el estado del campo.
Los análisis largos se pueden dividir en series de varias publicaciones, que crean audiencias que vuelven por la siguiente parte. Evita la trampa de publicar solo cuando terminas proyectos grandes; las lecciones intermedias suelen conectar más.
¿Cómo puede un científico de datos compartir su trabajo en LinkedIn sin exponer datos de la empresa?
Comparte el método y la magnitud, nunca los números crudos. "La cancelación bajó a doble dígito después de cambiar el disparador de la intervención" conserva la historia sin revelar cifras. Reconstruye los gráficos ilustrativos con datos sintéticos o públicos, usa cambios porcentuales en lugar de valores absolutos y elimina todo lo competitivamente sensible, como variables del modelo ligadas a la estrategia de negocio.
Los datasets públicos también son válidos para mostrar técnicas de principio a fin.
Herramientas gratis para LinkedIn
Da formato a tus publicaciones y revisa cómo se verán antes de publicarlas.
Más ideas de publicaciones