Datos para Proyectos de Machine Learning Cómo encontrarlos, evaluarlos y trabajar con ellos cuando no son ideales

Esta no es una lista de datasets. Es una guía para tomar decisiones reales sobre datos: cómo encontrarlos, cómo evaluarlos en horas y no en semanas, qué hacer cuando no son ideales y cuándo tiene sentido replantear el problema en lugar de seguir buscando.

He trabajado con datos en proyectos de industria cementera, ciencias sociales, salud y retail. Y en todos esos contextos, el patrón se repite: el problema no suele estar en el modelo. Está en cómo se entienden, preparan y evalúan los datos antes de llegar al modelo.

Esta guía documenta lo que he aprendido en ese proceso, incluyendo errores, casos reales y un par de herramientas propias que uso antes de comprometerme con cualquier dataset.

Tabla de contenido:

• Cuándo el problema está en los datos y no en el modelo
• El EDA que sí funciona versus el EDA de checklist
• Ingeniería de características: el paso que casi todos omiten
• Cómo buscar datasets de forma estratégica
• Disponible no significa descargable
• Dataset Novelty Score: cómo evitar datasets quemados
• Cómo evaluar un dataset en una o dos horas
• El método semáforo para categorizar variables
• Qué hacer cuando no existen los datos
• Caso real: influencia en redes sociales
• Dataset primero o problema primero
• Cómo trabajar con pocos datos
• Guía rápida de decisión
• Preguntas frecuentes

Cuándo el problema está en los datos y no en el modelo

Hay una señal muy clara que aparece en proyectos donde el problema no está siendo identificado correctamente: pruebas un modelo, pruebas otro, ajustas hiperparámetros, repites el proceso durante días, y nada mejora de forma significativa. En ese punto es muy probable que no estés frente a un problema de algoritmo. Estás frente a un problema de insumo.

La cantidad de datos es un factor, pero no el más importante. Lo que más indica que los datos van a generar problemas es cómo están organizados: si van a requerir muchas agregaciones, filtros complejos o transformaciones profundas para que tengan sentido, eso es una señal temprana de que el camino va a ser difícil.

Para detectarlo rápido, uso modelos simples basados en árboles. No como modelo final, sino como instrumento de diagnóstico. Un árbol de decisión bien entrenado sobre los datos crudos me da dos cosas de inmediato: la importancia de las variables y una primera verificación de coherencia. Si la importancia de las variables coincide aproximadamente con lo que las correlaciones sugieren y con lo que el sentido común del dominio indicaría, el dataset probablemente tiene potencial. Si no hay ninguna coherencia entre esas tres fuentes, el problema está en los datos.

Esto no es un proceso largo. Son unas horas de trabajo. Pero esas horas evitan semanas de optimización sobre un insumo que no va a funcionar sin importar qué algoritmo uses.

El EDA que sí funciona versus el EDA de checklist

Hay algo que casi nadie dice claramente sobre el Exploratory Data Analysis: hacerlo no es suficiente si no sabes qué estás buscando.

Lo que ocurre frecuentemente, tanto en proyectos académicos como en proyectos profesionales, es que el EDA se convierte en una checklist de pasos a completar: distribuciones, correlaciones, gráficos de dispersión, boxplots. Se marcan los cuadros, se reportan los resultados y se avanza al siguiente paso. Pero no se responde la pregunta real que debería guiar ese análisis: ¿estos datos me van a generar problemas después?

La diferencia entre hacer EDA como requisito y hacer EDA con criterio está en las preguntas que te haces mientras lo haces. No es solo generar las distribuciones, es preguntarte por qué esa variable tiene esa forma y si eso tiene sentido dado el problema. No es solo calcular correlaciones, es preguntarte si las relaciones que aparecen son coherentes con lo que sabes del dominio o si hay algo que no cuadra.

El tiempo que consume el EDA no está en el código. El código es rápido. Lo que consume tiempo es la interpretación: entender qué significa lo que estás viendo, validarlo contra el contexto del problema, iterar hasta que tengas una imagen clara de con qué estás trabajando. Esa parte no se puede automatizar ni delegar a una herramienta.

Un EDA bien hecho no termina con una lista de estadísticas descriptivas. Termina con una hipótesis clara sobre los riesgos que ese dataset va a presentar más adelante en el proyecto.

Ingeniería de características: el paso que casi todos omiten

El error más común que he visto en estudiantes que trabajan con datos es usar el dataset tal como viene. Ya tienen el target identificado, entrenan el modelo directamente y esperan resultados. Eso funciona a veces, pero deja valor sobre la mesa casi siempre.

La razón por la que los modelos más modernos y profundos han reducido la necesidad de ingeniería de características manual es que aprenden sus propias representaciones cuando tienen muchos datos. Pero esa condición, muchos datos, no siempre se cumple. Y cuando se trabaja con modelos clásicos de machine learning, la ingeniería de características puede ser la diferencia entre un resultado mediocre y uno que vale la pena defender.

Caso real: dataset ProstateX y la característica del círculo

Trabajé con el dataset ProstateX, un conjunto de imágenes de resonancia magnética para detección de cáncer de próstata. El problema con este dataset es que tiene información de más, en el sentido de que la imagen completa contiene mucho más que la próstata: tejido circundante, estructura ósea pélvica y otros elementos que para el modelo son ruido.

La próstata, en la mayoría de las imágenes, aparece en el centro. Lo que hice fue crear una característica que relaciona los píxeles en un círculo centrado en la imagen con los píxeles que están fuera de ese círculo. Es decir, en lugar de pasarle al modelo la imagen completa y pedirle que encontrara solo el patrón relevante, le di una medida de contraste entre el centro y el exterior.

El resultado fue significativo. Esa característica pasó a ser una de las más importantes en el modelo según la importancia de variables. Y tiene sentido desde el dominio: cuando hay cáncer de próstata, la estructura central de la imagen muestra diferencias respecto al tejido periférico que un médico también observaría.

Lo importante aquí no es la técnica específica. Es la lógica detrás: no le dijiste al modelo que encontrara el patrón solo. Le diste una pista fundamentada en el conocimiento del dominio. Eso es ingeniería de características.

Hay una advertencia importante: la ingeniería de características puede volverse en tu contra si la haces demasiado específica. Una feature muy ajustada a los patrones de un dataset particular puede mejorar el resultado en entrenamiento pero destruir la capacidad de generalización del modelo. La pregunta que guía cada decisión de este tipo debe ser: ¿esta característica captura algo real del problema, o solo captura ruido de este dataset en particular?

Cómo identificar qué características vale la pena crear

El proceso no es complicado en concepto: piensa qué patrón crees que existe en los datos que el modelo podría no detectar por sí solo con los datos disponibles, crea la característica que represente ese patrón, y evalúa si mejora o no. Si no mejora, descártala. Si mejora y tiene sentido en el dominio, quédate con ella.

La ingeniería de características es donde el conocimiento del dominio se convierte en ventaja técnica. Y en proyectos académicos es exactamente el tipo de contribución que un comité reconoce como criterio de diseño, no solo aplicación de un modelo.

Cómo buscar datasets de forma estratégica

La forma que mejor me ha funcionado, y que recomiendo consistentemente, es buscar en Google Scholar el tipo de clasificación o tarea que te interesa junto con la palabra "dataset". Lees los artículos recientes que aparezcan, ves qué datasets han utilizado y verificas cuáles están disponibles abiertamente.

Esta estrategia tiene una ventaja que Kaggle o Hugging Face no dan directamente: los artículos te dicen qué se ha hecho con ese dataset, qué resultados se han obtenido y qué preparación requirió. Eso te da contexto para evaluar si vale la pena usarlo y qué puedes aportar que sea diferente.

Kaggle y Hugging Face son fuentes válidas, pero hay que usarlas con criterio. Antes de comprometerte con un dataset de cualquier fuente, necesitas entender cómo fue construido, quién lo recolectó y bajo qué condiciones. Un dataset es confiable cuando la documentación explica claramente el proceso de recolección, quién lo validó y, mejor aún, cuando hay un artículo publicado en una revista indizada que respalda su construcción.

Si la documentación es pobre, si nadie habla del dataset o si lo poco que encuentras genera dudas sobre su origen, eso es una señal de alerta suficiente para buscarlo en otro lado.

Disponible no significa descargable

Este es uno de los errores más costosos en tiempo que he visto repetirse: un estudiante o profesional encuentra un dataset que parece perfecto, lo propone como base de su proyecto o tesis, avanza semanas en la planificación y luego descubre que no puede acceder a los datos.

El dataset "existe" en una página, en un repositorio o en un artículo, pero descargarlo requiere una cuenta institucional, una solicitud formal a la organización que lo generó, un proceso de aprobación que puede tardar meses o un pago que no estaba contemplado.

La regla es simple: antes de proponer cualquier dataset como base de tu proyecto, descárgalo. No asumas que porque aparece en una lista de fuentes abiertas o porque un artículo lo cita como disponible, tú vas a poder acceder a él en las condiciones que necesitas.

Una vez que lo tienes descargado, haz una prueba rápida: un EDA básico y un modelo simple de árbol. Esas dos horas de trabajo inicial te van a dar información mucho más valiosa que semanas de planificación basada en supuestos. Si con esa prueba rápida obtienes resultados que son coherentes y prometedores, entonces sí vale la pena invertir tiempo en profundizar. Si en esa prueba rápida todo se complica sin que sea obvio por qué, es mejor saberlo antes de comprometerse.

Dataset Novelty Score: cómo evitar datasets quemados

En proyectos académicos, usar un dataset que ya ha sido extensamente trabajado en la literatura es un problema real. No porque no se pueda usar, sino porque reduce el espacio de contribución disponible: si ese dataset ya tiene decenas de papers con modelos optimizados, lo que aportes tiene que ser suficientemente diferente para justificarse.

Para estimar qué tan saturado está un dataset en la literatura, uso una métrica que llamo Dataset Novelty Score. Es una herramienta en beta, pero funciona bien como primera aproximación para tomar esta decisión.

Cómo se calcula el Dataset Novelty Score

El cálculo es sencillo y se hace con búsquedas en Google Scholar:

• D: número de papers del dominio publicados en los últimos 3 años (por ejemplo, "detección de cáncer de próstata machine learning").
• DS: número de papers del dominio publicados en los últimos 3 años que mencionan específicamente ese dataset.
• DNS = 1 − (DS / D)

Un DNS cercano a 1 indica que el dataset es poco utilizado en la literatura reciente, lo que representa más oportunidad de contribución. Un DNS cercano a 0 indica que el dataset es muy frecuente en el dominio y el espacio para diferenciarse es más estrecho.

Cómo interpretar el resultado

El DNS no descarta un dataset automáticamente. Un dataset con DNS bajo puede seguir siendo válido si tu contribución no depende de la novedad del dataset sino de la novedad del enfoque, la aplicación o la ingeniería aplicada sobre él. Lo que el DNS sí te da es una señal temprana: si el DNS es bajo y tu contribución tampoco es especialmente diferente en lo técnico, ese es el momento de buscar alternativas antes de avanzar.

En la práctica, uso el DNS junto con la evaluación del artículo más reciente que usa ese dataset: si ese artículo ya alcanzó métricas muy altas con técnicas establecidas, el margen de mejora es pequeño y hay que tenerlo en cuenta desde el diseño del proyecto.

Cómo evaluar un dataset en una o dos horas

Cuando encuentro un dataset en Google Scholar, Kaggle o Hugging Face, el proceso que sigo antes de tomar cualquier decisión sobre usarlo tiene cuatro pasos. Todos caben en una o dos horas de trabajo.

Paso 1: leer la descripción con criterio

El primer paso no es descargar el dataset. Es leer cómo está descrito: quién lo generó, bajo qué condiciones fue recolectado y qué variables contiene. Si la descripción es pobre o no menciona el proceso de recolección, eso ya es información: indica que la trazabilidad del dataset es baja y que confiar en él para un proyecto académico o profesional es arriesgado.

Leo también si hay un artículo de referencia. Un dataset respaldado por un paper en una revista indizada tiene un nivel de validación que un dataset de repositorio sin documentación no tiene. No es un requisito absoluto, pero sí cambia el nivel de confianza.

Paso 2: revisar la estructura

Antes de ejecutar cualquier código, reviso si el dataset es tabular, de imagen o de texto; si el target está claramente identificado; y si las variables tienen nombres y tipos que permiten entender de qué van. No me fijo en el tamaño al principio. Si un dataset está publicado y abierto, generalmente tiene datos suficientes para al menos una evaluación inicial. Lo que más me importa en este paso es si voy a entender rápido de qué van los datos o si voy a necesitar mucho trabajo solo para orientarme.

Paso 3: prueba rápida con modelo de árbol

Con el dataset descargado, entreno un modelo basado en árboles, que puede ser un árbol de decisión o un Random Forest sencillo, sobre los datos tal como vienen. No busco optimizar nada en este paso. Busco tres cosas: que el modelo entrene sin errores, que la importancia de variables sea coherente con el dominio y que los resultados iniciales no sean completamente aleatorios.

Si las variables más importantes tienen sentido desde el problema, si las distribuciones no muestran nada raro y si el resultado inicial, aunque no sea bueno, es al menos consistente, entonces el dataset tiene potencial y vale la pena seguir.

Paso 4: verificar coherencia entre correlaciones e importancia de variables

El último paso de la evaluación rápida es comparar lo que las correlaciones sugieren con lo que la importancia de variables del árbol indica. Si las dos fuentes apuntan en la misma dirección y eso es coherente con el sentido común del dominio, tengo suficiente confianza para invertir más tiempo en ese dataset. Si hay contradicciones sin explicación, lo anoto como señal de alerta y evalúo si tiene solución antes de continuar.

Señales que me hacen descartar un dataset rápidamente

Documentación inexistente o muy pobre. Dataset en un repositorio de GitHub sin Readme claro y sin ningún artículo o blog que lo respalde. Dificultad para descargarlo o acceso condicionado a aprobaciones que pueden tardar semanas. Y también: que nadie en la literatura reciente lo esté usando, lo cual puede indicar que ya fue evaluado y descartado por razones que no son obvias a primera vista.

El método semáforo para categorizar variables cuando tienes el problema definido primero

Cuando el problema está definido desde el inicio y el reto es entender qué datos existen que puedan ser útiles, el proceso que sigo es distinto al de buscar un dataset listo. En ese caso, lo primero que hago es pedir que se traigan a la mesa todos los datos relacionados con el problema: no importa el formato, no importa si es un PDF, un Excel, una base de datos relacional o texto sin estructurar. Quiero ver todo antes de filtrar.

Una vez que tengo esa visión completa, trabajo junto con la persona que conoce el problema o el dominio, sea el cliente, el asesor o el experto de área, para categorizar cada fuente de datos en tres niveles usando lo que llamo el método semáforo:

• Verde: datos que claramente son relevantes, están disponibles y su uso tiene sentido para el problema definido.
• Amarillo: datos que podrían ser útiles pero que requieren validación adicional. Puede ser que la temporalidad no sea ideal, que haya dudas sobre su calidad o que no sea claro aún cómo integrarlos al problema.
• Rojo: datos que no tiene sentido usar. Puede ser porque el servicio que los generaba ya no existe, porque la temporalidad no es compatible con el problema, o porque desde el conocimiento del dominio no aportan información relevante.

Este proceso no lo hago solo. La participación del experto del dominio es fundamental porque hay razones para clasificar un dato en rojo que no son técnicas: razones de negocio, de contexto histórico, de cambios en el proceso que generó los datos. Sin esa perspectiva, puedo terminar usando datos que parecen técnicamente correctos pero que no representan la realidad del problema.

El resultado del método semáforo es una categorización clara que reduce el espacio de trabajo: en lugar de intentar usar todo, sabes exactamente con qué tienes que trabajar y por qué. Eso acelera todo el proceso posterior.

Qué hacer cuando no existen los datos

La ausencia de datos es casi siempre ausencia de acceso, no ausencia real de información. Los datos generalmente existen. Lo que no existe es una forma directa de llegar a ellos. Esa distinción cambia completamente cómo se aborda el problema.

Cuando no hay acceso a los datos que necesitas, las opciones son tres: buscar un proxy, generar datos sintéticos o replantear el problema. La elección entre estas tres depende del contexto del proyecto.

En un proyecto académico, la primera pregunta es qué le parecen al asesor las tres opciones. Esa conversación es parte del proceso de diseño y hay que tenerla antes de comprometerse con una dirección. En un proyecto de negocio, la pregunta es cuál de las tres opciones tiene mejor relación entre costo de implementación, tiempo requerido e impacto esperado en el objetivo.

Un proxy bien justificado no es una solución de segunda categoría. Es una decisión de diseño. Lo que implica es que el problema original se replantea de forma que el proxy pueda responderlo, sin perder el objetivo principal. Eso requiere trabajo conceptual, pero es trabajo que le da solidez al proyecto.

Caso real: modelar influencia en redes sociales cuando los datos no son accesibles

El caso más difícil que he tenido en términos de acceso a datos fue un proyecto de ciencias sociales donde el objetivo era modelar el poder de influencia de influencers a través del comportamiento de sus seguidores frente a productos específicos.

El problema conceptual estaba bien definido: la influencia se mide indirectamente a través de los comentarios que los seguidores hacen en redes sociales en respuesta a menciones de un producto. Ese tipo de datos existe en volúmenes enormes. El problema es que no era accesible bajo las condiciones del proyecto.

Meta no permite la extracción de datos de comentarios para proyectos externos, salvo una API muy restringida para contenido político. X, antes Twitter, comenzó a cobrar por el acceso a su API en condiciones que hacían inviable el proyecto económicamente. LinkedIn no era relevante para este tipo de análisis. Las opciones que parecían obvias estaban cerradas.

Lo que hicimos fue redirigir hacia YouTube. La justificación fue sólida: YouTube funciona en muchos contextos como motor de búsqueda de decisión de compra, especialmente en categorías de productos donde el contenido de video influye directamente en la intención de compra. La API de YouTube permite acceder a comentarios, métricas de engagement y datos de contenido de forma abierta, dentro de los límites del proyecto.

El resultado fue un proxy bien justificado: no era exactamente el problema original, pero respondía al objetivo principal con datos reales y verificables. El problema se había replanteado de forma que seguía siendo académicamente válido y técnicamente ejecutable.

Lo que este caso ilustra es que la solución ante la falta de acceso a datos no es rendirse ni cambiar el tema por completo. Es entender qué parte del problema puedes seguir respondiendo con los datos que sí están disponibles, y ser riguroso en la justificación de por qué ese proxy es válido.

Si este proyecto hubiera sido de negocio en lugar de académico, la decisión habría requerido evaluar si el costo de obtener acceso a los datos originales, ya fuera pagando por APIs o estableciendo acuerdos formales con plataformas, tenía sentido frente al impacto esperado. A veces sí lo tiene. A veces no.

Dataset primero o problema primero: cuándo aplica cada uno

Esta no es una pregunta con respuesta única. Depende del contexto y de los recursos disponibles.

Empezar por el dataset tiene sentido cuando tienes poco tiempo, cuando estás en un proyecto académico donde la literatura ya respalda el uso de ese dataset, o cuando estratégicamente quieres elegir un tema que ya tenga datos nobles disponibles. En esos casos, identificar un dataset bien documentado con resultados prometedores en artículos recientes y con DNS alto es un punto de partida legítimo. De ahí defines qué problema puedes resolver con esos datos de forma que tu contribución sea válida.

Empezar por el problema es la ruta correcta cuando tienes un objetivo de impacto claro, cuando estás en un proyecto de negocio con un usuario real, o cuando la contribución que buscas depende de resolver un problema específico y no de explorar qué se puede hacer con un dataset disponible. En ese caso, el dataset viene después: primero entiendes qué necesitas y luego buscas si existe o cómo construirlo.

La distinción que importa

Lo que no funciona es confundir encontrar un dataset con tener un proyecto. Un dataset es un insumo. Un proyecto requiere un problema definido, una métrica alineada con ese problema y una forma de demostrar que la solución genera valor. Tener los datos es el inicio del proceso, no su resultado.

La razón por la que esta confusión es tan costosa es concreta: si no defines el problema primero, la métrica del modelo y la métrica del objetivo van a estar desalineadas. Vas a estar optimizando el cómo sin tener claro el qué. Y eso se traduce en trabajo duplicado cuando te das cuenta tarde de que lo que estabas midiendo no era lo que necesitabas.

Cómo trabajar con pocos datos

Trabajar con pocos datos no es automáticamente un problema. Depende del tipo de datos y del modelo que quieres usar.

Los datos tabulares, especialmente en dominios como finanzas, operaciones o datos estructurados de negocio, funcionan bien con datasets relativamente pequeños cuando los datos están limpios y bien organizados. Con 150 registros bien preparados puedes evaluar modelos de machine learning clásico con suficiente confianza. No para deep learning, pero sí para la mayoría de los enfoques que se usan en proyectos académicos de pregrado y maestría.

El error más frecuente con pocos datos es intentar usar modelos demasiado complejos. Un modelo complejo con pocos datos tiende a sobreajustar: aprende los detalles específicos del dataset de entrenamiento en lugar de los patrones generalizables. El resultado es métricas de entrenamiento buenas y métricas de validación malas.

Cuando los resultados no mejoran con pocos datos, la pregunta correcta antes de buscar más datos es si el procesamiento es el que puede mejorarse. Muchas veces agregar más datos no resuelve el problema si el problema está en cómo están preparados los que ya tienes. La ingeniería de características, la limpieza de valores atípicos y la normalización adecuada pueden tener más impacto que duplicar el tamaño del dataset.

Y si de plano los datos disponibles son insuficientes para cualquier enfoque razonable, el camino es evaluar si se pueden conseguir más, si se pueden generar de forma sintética o si el problema necesita replantearse para que sea resoluble con los datos que existen.

Guía rápida de decisión

Si tienes poco tiempo

Busca datasets existentes en Google Scholar usando el tipo de problema que te interesa más la palabra "dataset". Filtra por los últimos tres a cinco años. Prioriza los que tienen un artículo de referencia publicado. Descárgalos antes de comprometerte. Haz una prueba rápida con un árbol y verifica coherencia entre correlaciones e importancia de variables.

Si no tienes datos

Distingue entre no existen y no tengo acceso. Los datos casi siempre existen. Busca proxies: qué datos disponibles se aproximan al problema que quieres resolver y permiten replantearlo sin perder el objetivo principal. Si el proyecto es académico, discútelo con tu asesor. Si es de negocio, evalúa costo-beneficio de recolectar versus usar un proxy.

Si eres principiante o nivel intermedio

Evita datasets sin documentación clara. No uses fuentes que no puedas verificar. Y no asumas que un dataset está disponible hasta que lo hayas descargado y ejecutado una prueba mínima.

Si los resultados no mejoran

Antes de probar otro modelo, detente y revisa los datos. Verifica si hay ingeniería de características que puedas aplicar con conocimiento del dominio. Si ya probaste varios modelos y ninguno da resultados coherentes, el problema está en el insumo, no en el algoritmo.

Si quieres saber si vale la pena seguir un proyecto

Aunque los resultados no sean muy buenos, si la prueba rápida genera algún insight coherente con el problema o con la contribución que buscas, vale la pena seguir explorando. Si después de tres días de pruebas no hay forma de que los datos respondan ninguna versión razonable del problema, ese es el momento de replantear el tema.

Preguntas frecuentes sobre datos en proyectos de machine learning

¿En qué momento te das cuenta de que el problema está en los datos y no en el modelo?

Cuando pruebas varios modelos, ajustas hiperparámetros y nada mejora de forma significativa. En ese punto casi siempre el problema es el insumo: datos mal organizados, variables incoherentes o un target que no captura bien lo que quieres predecir.

¿Cómo saber en pocas horas si un dataset sirve para un proyecto de machine learning?

Lee la descripción del dataset, revisa la estructura y el target, descárgalo y ejecuta un modelo simple de árbol. Si la importancia de variables es coherente con las correlaciones y con el sentido del dominio, el dataset tiene potencial. Si no hay coherencia sin que sea obvio por qué, es una señal de alerta.

¿Qué es el Dataset Novelty Score y para qué sirve?

Es una métrica para estimar qué tan saturado está un dataset en la literatura reciente. Se calcula como DNS = 1 − (papers que usan el dataset en los últimos 3 años / papers totales del dominio en los últimos 3 años). Un DNS alto indica que el dataset es poco utilizado y tiene más valor para contribuciones académicas.

¿Qué hacer cuando no existe un dataset para mi problema de machine learning?

Buscar un proxy: un dataset que permita replantear el alcance del problema sin perder el objetivo principal. En proyectos académicos, discutirlo con el asesor. En proyectos de negocio, evaluar el costo de recolectar versus el impacto de usar un proxy bien justificado.

¿Es mejor empezar un proyecto de machine learning por los datos o por el problema?

Depende del contexto. Si tienes poco tiempo o el proyecto es académico, empezar por un dataset disponible puede ser estratégico. Si buscas impacto real o estás en negocio, definir el problema primero es la ruta correcta. En todos los casos, el problema define el valor del proyecto; los datos son el medio.

¿Cuál es el error más común al trabajar con datos en machine learning?

Usar los datos tal como vienen sin preguntarse qué ingeniería de características podría mejorar el resultado. Y también: asumir que un dataset está disponible sin descargarlo antes de comprometerse con el proyecto.

Continúa con estos recursos del mismo nivel

• Cómo definir el problema en un proyecto de machine learning
• Cómo usar machine learning en tu tesis de pregrado o posgrado

O regresa al pilar principal sobre cómo diseñar un proyecto de machine learning antes de programar.

Si ya tienes datos pero no estás seguro de cómo convertirlos en un proyecto completo con una contribución clara, puedes escribirme directamente. Muchas veces la diferencia entre un proyecto que avanza y uno que se estanca está en cómo se estructuran esas primeras decisiones sobre los datos.