Medición antes que promesa
Antes de proponer nada se mide el punto de partida: tasa de error actual, tiempo por informe, volumen de registros duplicados. Sin ese dato no existe comparación posible ni forma de demostrar que el resultado sirve.
Markdex · Ciencia de datos aplicada · Sevilla
Método de trabajo y criterios de análisis de datos
Este documento describe cómo se plantea, ejecuta y valida un análisis en Markdex. Se registra el estado del cliente antes de tocar un solo dato, se fijan los parámetros del experimento, se ejecuta el modelo y se comparan los resultados con la medición de control. Sin partidas ocultas y sin promesas que no puedan comprobarse con una métrica.
- Métrica de referencia
- AUC-ROC 0,87
- Plazo habitual de entrega
- 8 – 12 días
- Diagnóstico inicial
- Sin coste
Perfil del analista
Quién ejecuta el análisis y con qué criterio
Trabajo de forma directa, sin intermediarios comerciales ni equipos de cuenta que reenvíen el encargo. El análisis lo ejecuto yo: desde la revisión del archivo original hasta la entrega del notebook ejecutable. Eso implica que la persona que responde a tus preguntas es la misma que ha escrito el código y la que puede explicar por qué un modelo ha descartado una variable.
La formación base es estadística aplicada con Python: pandas para la preparación, scikit-learn para clasificación y regresión, y matplotlib junto con seaborn para la visualización. En la página principal de Markdex Data Science & IA hay un resumen de los servicios que se cubren; aquí solo detallo cómo se trabaja por dentro.
Trabajo directo, sin capas
No hay agencia intermedia ni subcontrata del subcontrata. Lo que se acuerda en la primera visita es lo que se ejecuta, y los ajustes de alcance se documentan por escrito antes de tocar el dataset.
Resultado reproducible
La entrega incluye el script, las versiones de librería y la semilla aleatoria. Cualquier persona con el mismo archivo y el mismo entorno obtiene los mismos números: si no se reproduce, el trabajo no está terminado.
Protocolo de ejecución
Hipótesis, condiciones y control de la prueba
Todo encargo se formula como una hipótesis verificable. Un ejemplo real: «el tiempo de respuesta a una incidencia se reduce si se clasifican las solicitudes por urgencia antes de asignarlas». A partir de ahí se define qué variable mide la mejora, con qué umbral se acepta y qué se considera fracaso. Escribir el criterio de aceptación antes de entrenar el modelo evita el clásico ajuste a posteriori de la métrica que más conviene.
Las condiciones del experimento también se fijan por escrito: periodo de datos utilizado, filtros aplicados, tratamiento de nulos y variables excluidas por fuga de información. Si el cliente aporta un histórico de dos años, se trabaja con el mismo corte temporal en todas las iteraciones para que las comparaciones entre versiones del modelo sean válidas.
El detalle técnico del enfoque predictivo está publicado en la prueba de demanda con Python, y los criterios de representación gráfica en el informe de visualización avanzada.
Parámetros y control
Fases del trabajo y valores de referencia
Las cinco fases siguientes se repiten en todos los encargos, con independencia del tamaño del dataset. Cada fase deja un entregable concreto y una medición asociada, de modo que el cliente sabe en qué punto está el trabajo y qué falta para cerrarlo.
- 01
Diagnóstico y medición de control
Revisión del archivo original, recuento de registros, porcentaje de nulos y reglas de negocio vigentes. Se cierra con una cifra base documentada, que será la referencia contra la que se compare todo lo demás.
- 02
Definición de la hipótesis y del umbral
Se acuerda por escrito qué métrica decide el éxito del análisis y a partir de qué valor se considera aceptable. El umbral se fija antes de entrenar; cambiarlo después invalida el experimento.
- 03
Preparación reproducible de los datos
El script de limpieza se versiona y se ejecuta siempre sobre la copia en bruto. Nada se corrige a mano en la hoja de cálculo: si una transformación no está en el código, no existe.
- 04
Entrenamiento y validación cruzada
Se comparan al menos dos modelos, uno simple como control y otro de mayor capacidad. Se documentan los resultados de cada pliegue y no solo la media, porque una desviación alta entre pliegues indica que el modelo no es estable.
- 05
Entrega y comparación con el control
Se presenta el notebook ejecutable, el informe de resultados y la comparación directa con la cifra base del paso 01. Si la mejora no supera el umbral acordado, se dice con los números delante.
| Parámetro | Valor registrado | Observación |
|---|---|---|
| Muestra de entrenamiento | 12.400 registros | Partición 70/15/15 estratificada |
| Variables predictoras | 34 (18 numéricas, 16 categóricas) | 4 descartadas por fuga de información |
| Métrica principal | AUC-ROC 0,87 | Línea base del cliente: 0,71 |
| Error de clasificación | 11,4 % | Validación cruzada de 5 pliegues |
| Tiempo de ejecución | 4 min 12 s | Python 3.11, 8 GB de RAM |
Los valores corresponden a un encargo de clasificación de incidencias. El desglose de precios por fases está en tarifas de talleres y análisis de datos.
Preguntas frecuentes
Dudas habituales antes de encargar un análisis
¿Cuánto tarda un análisis estándar?
Entre 8 y 12 días laborables para un dataset de hasta 50.000 registros. El plazo incluye la fase de diagnóstico, la preparación de datos y dos iteraciones de modelo. Los volúmenes mayores se presupuestan por separado después de revisar el archivo.
¿Qué hace falta para el primer diagnóstico?
Basta con una exportación real de los datos, aunque esté sucia, y una frase sobre la decisión que se quiere tomar. El diagnóstico inicial no tiene coste y en él se comprueba si el volumen y las variables disponibles permiten plantear el modelo.
¿Se entrega el código?
Sí. La entrega incluye el notebook completo, el archivo de requisitos con las versiones de librería y una nota con la semilla aleatoria utilizada. Sin eso, el resultado no sería verificable por un tercero ni por tu equipo técnico.
¿Cómo se mide la eficacia del trabajo?
Comparando la métrica acordada antes de empezar con el valor obtenido al final, sobre el mismo corte temporal. La diferencia se presenta en una tabla junto a la línea base. Si no hay mejora medible, el informe lo indica con claridad.
Siguiente paso
Ver el método aplicado a un caso concreto
La forma más rápida de evaluar si este método encaja con tu problema es leer un caso completo, con la medición de control y los números finales. En la sección de trabajos hay ejemplos de clasificación de incidencias, previsión de demanda y cuadros de mando operativos.
Análisis predictivo con Python: prueba de demanda
Hipótesis, partición de datos y comparación de errores en una prueba de previsión con datos reales.
Visualización avanzada de datos con Python
Parámetros de escala, color y etiquetado que hacen legible un cuadro de mando sin deformar la lectura.
Tarifas de talleres y análisis de datos
Precio por fase, alcance de cada partida y qué se incluye en el diagnóstico inicial gratuito.