19  Introducción a la Minería de Datos y sus Frameworks de Proceso

Autor/a

Diego Villalba

Fecha de publicación

16 de octubre de 2026

1 La pregunta que abre el capítulo

Imagina que acabas de incorporarte como analista de datos a BigMart, una cadena minorista con outlets de distinto tamaño y formato en varias ciudades — el mismo caso que se retoma en detalle a lo largo de esta unidad (Analytics Vidhya 2016). En tu primera semana, la directora comercial te muestra un reporte y te hace una pregunta que suena simple:

“Aquí está Item_DT_1985, un paquete de galletas. En el outlet OUT027 se vende como pan caliente; en el OUT010, casi nadie lo compra. Es el mismo producto, el mismo precio de lista. ¿Por qué se vende tan distinto? Y más importante: ¿qué deberíamos hacer al respecto?”

Esta pregunta —aparentemente trivial— es en realidad la puerta de entrada a toda la disciplina que estudia este capítulo. Note que la directora no preguntó “muéstrame las ventas de Item_DT_1985 por outlet” (eso ya lo tiene, en el reporte que sostiene). Preguntó por qué, y qué hacer. Responder eso requiere algo que ninguna consulta a una base de datos puede entregar por sí sola: un modelo de las relaciones que gobiernan el fenómeno.

Este capítulo construye, paso a paso, el vocabulario y las herramientas de proceso necesarias para convertir una pregunta como esta en un proyecto ejecutable. La ruta es la siguiente: primero se distingue la minería de datos de la simple recuperación de datos; después se advierte sobre la trampa más común del oficio —confundir correlación con causalidad—; luego se catalogan las tareas centrales de la minería de datos; y finalmente se presentan los frameworks de proceso (KDD, CRISP-DM, SEMMA, TDSP y sus evoluciones modernas) que estructuran cómo, en la práctica, un equipo pasa de la pregunta de la directora a una decisión de negocio. A lo largo del capítulo volveremos varias veces a Item_DT_1985 y a BigMart para anclar cada idea nueva en un caso concreto.

2 Recuperación de datos versus minería de datos

Antes de convocar a un equipo de ciencia de datos, vale la pena preguntarse si la pregunta de la directora puede responderse con una simple consulta. La respuesta revela la diferencia central de este capítulo.

La recuperación de datos responde preguntas cuya forma ya está completamente definida por quien pregunta, antes de tocar el sistema. Es una transformación de la forma “dame los registros que satisfacen la condición \(C\)”, donde \(C\) es conocida de antemano y el resultado es un subconjunto del repositorio. Si la directora hubiera preguntado “¿cuántas unidades de Item_DT_1985 se vendieron en OUT027 el trimestre pasado?”, la respuesta es una consulta SQL: agregar Item_Outlet_Sales filtrando por Item_Identifier y Outlet_Identifier. No hay nada que aprender; solo hay que filtrar y sumar.

La minería de datos, en cambio, busca responder preguntas donde la forma de la relación es desconocida. El objetivo no es filtrar, sino aprender: estimar funciones, reglas o estructuras que expliquen o anticipen un fenómeno. La pregunta real de la directora — ¿qué hace que un producto rote distinto entre outlets, y qué deberíamos hacer? — no tiene una columna que la responda directamente. Obliga a definir variables candidatas (Outlet_Type, Outlet_Size, Item_Visibility, Item_MRP…), construir un conjunto de datos adecuado, elegir un criterio de evaluación y cuantificar qué tan confiable es la respuesta.

En la práctica, todo proyecto de minería de datos empieza con muchas consultas de recuperación (explorar, filtrar, contar): son el insumo del análisis exploratorio de datos que se desarrolla en la siguiente unidad. La diferencia importa porque confundir ambas actividades lleva a un error común: tratar un hallazgo exploratorio (un filtro, un promedio) como si fuera un modelo validado, sin haber pasado por el proceso de aprendizaje y validación que la minería de datos exige.

3 Correlación y causalidad: la primera trampa

Supón que, al explorar los datos de BigMart, encuentras que Item_Visibility (el porcentaje de espacio en anaquel que ocupa un producto) está correlacionada negativamente con Item_Outlet_Sales: los productos con más visibilidad tienden a vender menos, no más. Es tentador concluir: “hay que reducir la visibilidad de los productos para aumentar ventas” — una conclusión que, llevada a producción, sería un despropósito.

Una asociación estadística (correlación) no garantiza un vínculo causal. La razón técnica es que los datos observacionales pueden estar dominados por variables omitidas, selección no aleatoria, confusores o retroalimentaciones entre variables (Pearl 2009). En el caso de BigMart, una explicación mucho más plausible es un confusor: los productos de baja rotación (por ejemplo, artículos de nicho o de temporada) se colocan deliberadamente en espacios más visibles precisamente porque no se venden solos, mientras que los productos de alta rotación (leche, pan) no necesitan visibilidad extra porque el cliente ya los busca activamente. La demanda base del producto está causando tanto la visibilidad asignada como, indirectamente, el patrón de ventas — no es la visibilidad la que causa las ventas bajas.

Para hablar de causalidad con solidez, típicamente se requiere un diseño experimental —idealmente aleatorizado. El experimento por excelencia en sistemas digitales es la prueba A/B: se asigna aleatoriamente una intervención (por ejemplo, mover un subconjunto de productos a estantes más visibles en una muestra aleatoria de outlets) a un grupo de tratamiento y se compara contra un grupo control bajo una métrica previamente definida (Kohavi et al. 2020). Empresas con alto volumen de experimentación, como Netflix, documentan públicamente cómo combinan experimentación offline (entrenar y validar modelos con datos históricos) con experimentación online (A/B testing en producción) antes de lanzar un cambio a todos sus usuarios (Netflix Technology Blog 2016). Incluso con un buen diseño A/B, sigue siendo necesario vigilar violaciones: interferencia entre unidades (spillover, por ejemplo si mover un producto en un outlet afecta las ventas de otro producto en el mismo estante), cambios temporales (estacionalidad, como en la Navidad) y sesgos de medición.

4 Las tareas centrales de la minería de datos

Una vez que la pregunta de negocio se reconoce como un problema de minería de datos —y no de simple recuperación—, el siguiente paso es identificar qué tipo de tarea es. La literatura clásica (Han et al. 2011; Tan et al. 2006) organiza estas tareas en dos grandes familias: supervisadas, cuando existe una variable objetivo que se quiere predecir o explicar, y no supervisadas / de descubrimiento, cuando el objetivo es encontrar estructura sin una etiqueta previa.

4.1 Clasificación (aprendizaje supervisado)

La clasificación modela una variable objetivo categórica. Dado un vector de atributos \(\mathbf{x}\in\mathbb{R}^p\), se aprende una función \(f(\mathbf{x})\in\{1,\dots,K\}\) que minimiza una pérdida esperada (por ejemplo, entropía cruzada o error 0-1 aproximado). El desempeño se valida con esquemas como train/validation/test o k-fold cross-validation, analizando sensibilidad a desbalance de clases, umbrales de decisión y costos asimétricos.

En BigMart: transformar Item_Outlet_Sales en una etiqueta binaria (“rotación alta” / “rotación baja” por outlet) y predecirla a partir de Outlet_Type, Outlet_Size e Item_Type, para decidir qué outlets necesitan intervención comercial prioritaria.

4.2 Regresión (aprendizaje supervisado)

La regresión se usa cuando la variable objetivo es numérica. El problema consiste en aproximar una función \(y \approx g(\mathbf{x})\) bajo un criterio como MSE o MAE. La selección del modelo depende de la estructura esperada: linealidad, heterocedasticidad, colinealidad y presencia de outliers.

En BigMart: esta es, literalmente, la tarea central del dataset — predecir Item_Outlet_Sales (numérica) a partir de los atributos del producto y del outlet. Es el ejercicio de modelado que se retoma con detalle en la unidad de clasificadores y regresión.

4.3 Clustering (aprendizaje no supervisado)

El clustering busca particiones naturales sin etiquetas. El caso prototípico es \(k\)-means, que minimiza la suma de distancias cuadráticas a centroides. Exige decisiones técnicas: estandarización de variables, selección de \(k\), sensibilidad a inicialización y validez del supuesto de clusters aproximadamente esféricos.

En BigMart: segmentar los outlets (no los productos) según su perfil de ventas, tamaño y tipo, para descubrir si existen “arquetipos” de tienda —por ejemplo, supermercados urbanos grandes contra tiendas de conveniencia pequeñas— que expliquen buena parte de la variación observada.

4.4 Reglas de asociación

Las reglas tipo “si A entonces B” formalizan co-ocurrencias, típicamente en análisis de canasta de mercado. Las métricas clave son soporte, confianza y lift, discutidas en profundidad en la unidad de reglas de asociación.

Nota honesta sobre BigMart: el dataset de BigMart está agregado a nivel producto–outlet (una fila resume ventas históricas), no a nivel transacción individual. Por lo tanto, las reglas de asociación no aplican directamente sobre estos datos: no sabemos qué productos se compraron juntos en el mismo ticket. Para ilustrar esta tarea se necesita un dataset transaccional distinto —el clásico ejemplo es descubrir que quienes compran jarabe para la tos tienden a comprar también pastillas para la garganta, lo que habilita cross-sell o colocación conjunta en anaquel. Si BigMart quisiera aplicar esta tarea, tendría que capturar primero el detalle de cada ticket de compra, algo que su sistema actual no registra.

4.5 Detección de anomalías

Detecta observaciones raras respecto a un patrón normal. Se puede abordar como distancia a vecindarios (LOF), separación por particiones (Isolation Forest), reconstrucción (autoencoders) o modelos probabilísticos. Un punto crítico es que “raro” no siempre significa “problema”: requiere validación operacional y un proceso para manejar falsos positivos.

En BigMart: detectar outlets cuyo patrón de ventas se desvía abruptamente de lo esperado para su tipo y tamaño —una señal temprana de un problema operativo (desabasto, error de captura, cierre parcial) o de una oportunidad no explicada que vale la pena investigar.

5 Frameworks de proceso: cuatro formas de responder la misma pregunta

Con las tareas centrales identificadas, falta resolver un problema distinto: ¿cómo se organiza el trabajo desde que la directora hace la pregunta hasta que existe una decisión sustentada en datos? A medida que la disciplina creció en volumen, variedad y velocidad de datos, se hizo necesaria la estandarización de prácticas; de ahí emergen los frameworks de proceso: guías end-to-end para conducir proyectos de analítica y minería de datos de manera consistente y repetible.

No todos los frameworks enmarcan la misma pregunta de la misma forma. El siguiente comparador interactivo aplica la pregunta de la directora de BigMart a través de cuatro frameworks —KDD, CRISP-DM, SEMMA y TDSP— para mostrar en qué difieren.

Comparador de frameworks — misma pregunta, cuatro lentes
Pregunta: "¿por qué el mismo producto se vende distinto entre outlets de BigMart, y qué hacemos al respecto?"
Selección
tablas producto/outlet/ventas
Preproceso
pesos faltantes, etiquetas inconsistentes
Transformación
codificar categorías, escalar
Data Mining
modelos/patrones
Interpretación
& evaluación
Conocimiento
patrón explicado
Énfasis: descubrimiento y explicabilidad del patrón
KDD trataría la pregunta como un problema de descubrimiento. Seleccionaría las tablas de ventas, productos y outlets; limpiaría inconsistencias (pesos faltantes, etiquetas de grasa mal codificadas); transformaría variables; aplicaría un método de minería (por ejemplo, un árbol de regresión); y se detendría a interpretar qué combinaciones de atributos explican mejor la dispersión de ventas — priorizando un patrón comprensible para la directora sobre el modelo con menor error posible.
Negocio
objetivo y KPI
Datos
qué existe y su calidad
Preparación
limpieza, features
Modelado
entrenar y comparar
Evaluación
¿cumple el objetivo?
Despliegue
producción + monitoreo
Iterativo: evaluación insatisfactoria regresa a datos o modelado.
Énfasis: gobierno del proyecto end-to-end, negocio y despliegue
CRISP-DM empezaría por convertir la pregunta en un objetivo de negocio medible — por ejemplo, "reducir en 15% la dispersión de ventas entre outlets comparables en dos trimestres" — y definiría cómo se sabrá si el proyecto tuvo éxito. Solo después de auditar qué datos existen construiría un modelo, y ese modelo tendría que desplegarse y monitorearse en producción, no quedarse en un notebook de análisis.
Sample
muestra de outlets
Explore
visualizar relaciones
Modify
features nuevas
Model
probar varios algoritmos
Assess
comparar desempeño
Assess retroalimenta a Explore/Modify: ciclo corto de iteración.
Énfasis: iteración rápida de modelado
SEMMA asumiría que ya existe un dataset razonable —el histórico de ventas producto–outlet— y se concentraría en iterar rápido: muestrear una porción de outlets, explorar visualmente la relación con Item_MRP y Item_Visibility, construir variables nuevas, probar varios modelos (regresión lineal, árboles, gradient boosting) y comparar su error. No dice nada sobre si el objetivo de negocio está bien planteado ni sobre cómo desplegar el ganador.
Negocio
objetivo + roles
Datos
adquisición versionada
Modelado
experimentos trazables
Despliegue
servicio + CI/CD
Aceptación
validación con el cliente
Énfasis: equipo, reproducibilidad e ingeniería
TDSP abordaría la misma pregunta como un proyecto de equipo con roles explícitos (líder de proyecto, ingeniero de datos, científico de datos), versionando cada artefacto —código, datos, modelo— en un repositorio, documentando el trabajo en un backlog ágil, y dejando el modelo listo para servirse como un servicio con integración y despliegue continuos (CI/CD), no solo para responder la pregunta una sola vez.
Haz clic en cada pestaña. Las cuatro parten de la misma pregunta y del mismo dataset, pero producen entregables distintos.

5.1 KDD como modelo de descubrimiento

KDD (Knowledge Discovery in Databases) describe el flujo completo desde datos crudos hacia conocimiento: selección, preprocesamiento, transformación, minería y evaluación/interpretación, culminando en conocimiento accionable (Fayyad et al. 1996). Es especialmente útil cuando el objetivo es entender y extraer patrones explicables, además de modelar — la minería de datos propiamente dicha es solo una de sus cinco etapas, no el proceso completo.

5.2 CRISP-DM como marco de proyecto end-to-end

CRISP-DM (Cross-Industry Standard Process for Data Mining) organiza el proyecto en seis fases iterativas: comprensión del negocio, comprensión de los datos, preparación, modelado, evaluación y despliegue (Chapman et al. 2000; Shearer 2000). Su fortaleza es gestionar el ciclo completo con énfasis explícito en llevar resultados a operación (producción, monitoreo, impacto). Es, con diferencia, el framework más adoptado en la industria desde su publicación en 1999–2000, y es el que se desarrolla con mayor detalle en el resto de esta unidad, aplicado al caso BigMart.

5.3 SEMMA como pipeline práctico para iterar modelado

SEMMA (Sample, Explore, Modify, Model, Assess), originalmente asociado a las herramientas de SAS Institute (SAS Institute 2017), enfatiza el ciclo de modelado: muestrear, explorar, modificar (ingeniería de variables), modelar y evaluar. Es particularmente útil cuando ya existe un dataset razonablemente definido y el objetivo es optimizar desempeño comparando alternativas rápidamente — pero, a diferencia de CRISP-DM, no dice nada sobre cómo se llegó a ese dataset ni sobre qué pasa después de elegir el mejor modelo.

5.4 TDSP como alternativa moderna orientada a ingeniería

TDSP (Team Data Science Process), documentado y mantenido por Microsoft (Microsoft 2023), es un proceso de equipo que combina gestión, reproducibilidad e implementación con prácticas de ingeniería de software (versionado, artefactos, CI/CD). En comparación con CRISP-DM, enfatiza más explícitamente el “cómo se construye” en ambientes productivos —pipelines, repositorios, roles de equipo, trazabilidad—, aunque su esencia sigue siendo end-to-end y reconoce abiertamente su deuda con CRISP-DM.

6 Comparativa de frameworks

Framework Enfoque principal ¿Cuándo usarlo? Lo que menos enfatiza Entregable típico Aplicado a BigMart
CRISP-DM Proceso end-to-end orientado a negocio y despliegue Alinear problema, datos, modelo y operación con métricas de impacto Técnicas específicas (no dicta algoritmos) Modelo + plan de despliegue + monitoreo Objetivo → datos → modelo de ventas → despliegue de alertas por outlet
SEMMA Pipeline de modelado iterativo (centrado en desempeño) Ya se tienen datos y se quiere iterar rápido para mejorar métricas Contexto de negocio y despliegue operacional Comparativo de modelos y reporte de evaluación Probar 3–4 modelos para predecir Item_Outlet_Sales, elegir el mejor por RMSE
KDD Descubrimiento de conocimiento y patrones interpretables Extraer patrones/insights con interpretación validada Gestión del proyecto y despliegue Patrones/reglas + interpretación Descubrir qué combinación producto-outlet explica mejor la dispersión de ventas
TDSP End-to-end con énfasis en ingeniería y trabajo en equipo El resultado debe vivir como sistema (pipelines, CI/CD, reproducibilidad) Marco teórico de descubrimiento; más prescriptivo en implementación Pipelines + artefactos + despliegue versionado Servicio de predicción de ventas: ingesta → features → entrenamiento → registro → API
CRISP-ML(Q) (Studer et al. 2021) Evolución de CRISP-DM con aseguramiento de calidad explícito El modelo es crítico y necesita monitoreo formal de calidad en cada fase No es (aún) tan adoptado como CRISP-DM Checklist de calidad por fase + modelo monitoreado Definir umbrales de calidad de datos y de desempeño antes de desplegar el modelo de BigMart
ASUM-DM (IBM 2015) Evolución de CRISP-DM de IBM, con guías de gobierno e IA responsable La organización ya usa herramientas de IBM o necesita gobierno formal Es una extensión propietaria, menos documentada públicamente Artefactos de gobierno + modelo + despliegue —

6.1 Cómo se combinan en un proyecto real

En proyectos reales no es necesario elegir un único marco. Una estrategia común es usar CRISP-DM para gobernar el proyecto completo, aplicar SEMMA dentro de la fase de modelado para iterar eficientemente, y apoyarse en la lógica de KDD cuando el objetivo incluye extraer patrones explicables o reglas interpretables para la directora comercial.

7 Los frameworks en la nube: de la metodología a la herramienta

Un framework de proceso dice qué hacer en cada fase, pero no con qué. En la última década, los tres grandes proveedores de nube —además de plataformas como Databricks— han construido servicios administrados que se alinean, fase por fase, con CRISP-DM y TDSP, reduciendo la fricción de ingeniería que antes exigía cada etapa.

Fase (CRISP-DM / TDSP) AWS Azure Google Cloud Databricks / código abierto
Comprensión de negocio y datos Amazon QuickSight, Athena Power BI, Synapse Analytics Looker, BigQuery Databricks SQL, dbt
Preparación de datos AWS Glue / Glue DataBrew Azure Data Factory Dataflow, Dataprep Apache Spark (Databricks), dbt
Modelado Amazon SageMaker (Amazon Web Services 2024) Azure Machine Learning (Microsoft 2024) Vertex AI (Google Cloud 2024) Databricks ML + MLflow
Despliegue y monitoreo SageMaker Endpoints + Model Monitor Azure ML Endpoints + Model Monitoring Vertex AI Prediction + Model Monitoring MLflow Model Registry + Model Serving

Estas plataformas no reemplazan al framework: lo operacionalizan. TDSP, por ejemplo, nació explícitamente pensado para integrarse con Azure Machine Learning (Microsoft 2023): sus plantillas de estructura de proyecto y control de versiones están diseñadas para conectarse directamente con esa plataforma. De forma análoga, si el equipo de BigMart decidiera desplegar el modelo de predicción de ventas como un servicio que se actualiza automáticamente cada mes, necesitaría un registro de modelos, un pipeline de entrenamiento reproducible y un endpoint versionado — exactamente lo que ofrecen SageMaker, Azure ML, Vertex AI o Databricks, independientemente de si el equipo gobierna el proyecto con CRISP-DM o TDSP.

Dos consecuencias prácticas de esta convergencia entre frameworks y nube:

  1. La elección de framework y la elección de plataforma son decisiones distintas. Un equipo puede seguir fielmente CRISP-DM y desplegar en cualquiera de las cuatro columnas de la tabla anterior; el framework no impone el proveedor.
  2. Las plataformas modernas incorporan piezas que los frameworks clásicos dejaban implícitas, en particular el monitoreo continuo de data drift y desempeño del modelo en producción — la motivación detrás de evoluciones como CRISP-ML(Q) (Studer et al. 2021), que añade aseguramiento de calidad explícito en cada fase, y ASUM-DM (IBM 2015), la evolución de IBM hacia gobierno de datos e IA responsable.

8 Consideraciones éticas y de implementación

En minería de datos, el modelo aprende patrones del pasado; si el pasado está sesgado, el modelo puede amplificar sesgos. Si el histórico de ventas de BigMart refleja, por ejemplo, que ciertos outlets recibieron menos inversión en surtido por decisiones administrativas pasadas —no por falta de demanda real—, un modelo entrenado ciegamente sobre esos datos aprenderá y perpetuará esa asignación desigual. Por eso, además de métricas predictivas, se requiere evaluación de equidad (por grupo o segmento), explicación razonable del modelo y gobernanza de los datos usados.

En implementación, también importa la estabilidad operacional: un modelo “bueno” en validación puede fallar en producción si la distribución de los datos cambia (data drift), si el proceso de captura se modifica (un nuevo sistema de punto de venta), o si aparece variación estacional no vista en el entrenamiento. Por ello, el despliegue debe incluir monitoreo continuo: estadísticos de entrada, tasas de error, calibración y alertas, además de un protocolo explícito para reentrenamiento y auditoría — precisamente el vacío que frameworks como CRISP-ML(Q) buscan cerrar formalmente.

9 Resumen final

  • La recuperación de datos responde preguntas con forma conocida (\(C\) definida de antemano); la minería de datos aprende funciones, reglas o estructuras cuando la forma de la relación es desconocida.
  • Una correlación fuerte (por ejemplo, visibilidad vs. ventas en BigMart) no implica causalidad: siempre hay que preguntarse si un confusor no observado explica la asociación. Los diseños experimentales (A/B testing) son la vía más robusta hacia afirmaciones causales.
  • Las tareas centrales de la minería de datos son clasificación y regresión (supervisadas), clustering (no supervisada), reglas de asociación y detección de anomalías — no todas aplican a cualquier dataset: BigMart, por ejemplo, no tiene la granularidad transaccional que las reglas de asociación requieren.
  • KDD, CRISP-DM, SEMMA y TDSP son cuatro formas distintas de organizar el trabajo frente a la misma pregunta de negocio: KDD prioriza el descubrimiento interpretable, CRISP-DM gobierna el proyecto completo hasta despliegue, SEMMA acelera la iteración de modelado, y TDSP añade ingeniería de software y trabajo en equipo.
  • En la práctica, estos frameworks se combinan (CRISP-DM como gobierno, SEMMA/KDD dentro del modelado) en lugar de competir entre sí.
  • Las plataformas de nube (AWS SageMaker, Azure ML, Vertex AI, Databricks) operacionalizan las fases de estos frameworks, pero la elección de framework y la elección de plataforma son decisiones independientes.
  • Evoluciones recientes como CRISP-ML(Q) y ASUM-DM incorporan explícitamente lo que los frameworks clásicos dejaban implícito: aseguramiento de calidad, monitoreo de drift y gobierno responsable de los modelos en producción.

10 Preguntas de repaso

  1. ¿Cuál es la diferencia esencial entre una consulta de recuperación de datos y una tarea de minería de datos? Ilustra con un ejemplo de BigMart distinto al usado en el capítulo.
  2. Explica por qué una correlación fuerte entre Item_Visibility e Item_Outlet_Sales no implica que reducir la visibilidad de un producto vaya a aumentar sus ventas. ¿Qué confusor podría explicar la correlación observada?
  3. La directora de BigMart pregunta “¿por qué el mismo producto vende distinto en cada tienda?”. Redacta cómo KDD y cómo CRISP-DM formularían esta pregunta como un problema abordable, y señala al menos una diferencia clave en su enfoque.
  4. Da un ejemplo —de BigMart o de otro dominio— de cada una de las cinco tareas centrales de minería de datos: clasificación, regresión, clustering, reglas de asociación y detección de anomalías.
  5. ¿Por qué las reglas de asociación no se pueden aplicar directamente al dataset de BigMart tal como se describe en este capítulo? ¿Qué tendría que cambiar en los datos para que sí aplicaran?
  6. Compara SEMMA y CRISP-DM: ¿en qué escenario de proyecto elegirías apoyarte más en uno que en el otro?
  7. ¿Qué aporta TDSP que CRISP-DM no especifica explícitamente? Menciona al menos dos elementos concretos.
  8. Elige una fase de CRISP-DM o TDSP y menciona dos herramientas de nube, de proveedores distintos, que podrían usarse para implementarla.
  9. ¿Qué problema de los frameworks clásicos busca resolver CRISP-ML(Q)? ¿Por qué ese problema se volvió más urgente al llevar modelos a producción?
  10. Un modelo de BigMart que funcionaba bien en 2013 empieza a fallar en 2015. Menciona dos causas técnicas posibles y qué práctica de monitoreo, de las discutidas en el capítulo, ayudaría a detectarlas a tiempo.

Recursos y lecturas adicionales

Lecturas fundamentales

  • Fayyad et al. (1996) — el artículo original que define el proceso KDD y distingue explícitamente la minería de datos (una etapa) del descubrimiento de conocimiento (el proceso completo).
  • Chapman et al. (2000) y Shearer (2000) — la guía metodológica original de CRISP-DM y el artículo que la presentó como “el nuevo blueprint” de la industria.
  • Han et al. (2011) y Tan et al. (2006) — libros de texto de referencia para las tareas centrales de minería de datos (clasificación, regresión, clustering, reglas de asociación, anomalías).
  • Provost y Fawcett (2013) — una introducción muy accesible al pensamiento analítico de negocio detrás de la minería de datos, sin asumir formación matemática previa.
  • Pearl (2009) — la referencia canónica sobre inferencia causal y por qué la correlación no basta.
  • Kohavi et al. (2020) — guía práctica y rigurosa sobre el diseño de pruebas A/B en producción.

Documentación oficial de frameworks y plataformas

Videos y cursos

Caso de estudio de esta unidad

  • Analytics Vidhya (2016) — el dataset BigMart Sales, usado como hilo conductor en este capítulo y desarrollado en detalle en el resto de la unidad (comprensión de negocio, EDA, preprocesamiento y modelado).

Referencias