20 preguntas frecuentes de entrevista para Data Scientist. Data Science es un área muy demandada que convierte datos de producto, clientes y negocio en decisiones, experimentos, modelos e insights medibles. Las preguntas cubren distintos niveles, y puedes practicar respondiéndolas en voz alta en nuestro simulador de entrevistas.
1How do you explain foundational metrics like conversion rates or statistical significance to non-technical business stakeholders without using technical jargon?
When communicating foundational metrics to non-technical stakeholders, the key is to translate abstract formulas and statistical mechanics into intuitive user stories, decision confidence, and business risk. For conversion rate, rather than presenting a bare ratio or abstract percentage, frame it around concrete user counts: 'Out of every 100 people who landed on the checkout page, 5 completed a purchase.' This grounds the metric directly in observable customer behavior. For statistical significance, avoid formal null hypothesis terminology like alpha levels or rejection regions. Instead, explain it as confidence that an observed uplift is real rather than random noise or lucky timing. For instance: 'A statistically significant result means we are 95% confident this improvement reflects a genuine change in user behavior rather than random fluke. Rolling this out gives us high confidence of a positive outcome instead of reacting to random noise.'
## Experiment Results: New Checkout Flow
- Baseline Conversion: 5.0% (5 out of 100 visitors buy)
- Variant Conversion: 5.8% (5.8 out of 100 visitors buy, a +16% relative lift)
- Decision Confidence: 96% confidence (p = 0.04)
- Business Takeaway: The risk that this lift was just random chance is under 4%. Rolling this out is estimated to bring +$45k in monthly revenue.
2¿Cuál es la diferencia conceptual entre los joins inner, left, right y full outer, y cómo influye cada opción en la población analítica y en el tratamiento de valores NULL en el cálculo posterior de métricas?
Los joins inner, left, right y full outer definen qué registros se conservan al combinar tablas en función de claves coincidentes:
- Inner Join: Conserva únicamente los registros donde la clave de unión coincide en ambas tablas.
- Left (Outer) Join: Conserva todos los registros de la tabla izquierda y rellena las columnas de la tabla derecha con NULL cuando no hay coincidencia.
- Right (Outer) Join: Conserva todos los registros de la tabla derecha, rellenando con NULL las columnas no coincidentes de la tabla izquierda.
- Full Outer Join: Conserva todos los registros de ambas tablas, rellenando con NULL en cualquiera de los lados cuando no exista coincidencia.
Impacto en la población analítica y en el cálculo posterior de métricas:
La elección del tipo de join controla directamente la cohorte analítica y los denominadores utilizados en el cálculo de métricas. Un inner join involuntario entre una base de usuarios y una tabla de actividad o transacciones descarta a los usuarios inactivos, reduciendo el denominador únicamente a usuarios activos e inflando de forma artificial las tasas de conversión o retención. Por el contrario, los outer joins conservan la población base completa, pero introducen valores NULL para las filas sin coincidencia. Los cálculos posteriores deben gestionar estos valores: las funciones de agregación estándar de SQL como SUM() o AVG() ignoran los valores NULL, COUNT(columna) cuenta las entradas que no son NULL mientras que COUNT(*) cuenta todas las filas, y las operaciones aritméticas sobre valores NULL no procesados devuelven NULL.
-- Inner join silently shrinks denominator to purchasers only
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS inner_conv_rate
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
-- Left join preserves full user base for accurate metric computation
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS true_conv_rate
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id;
3In product experimentation, what does randomization achieve that simple before-after comparison usually cannot, and how would you explain the core causal claim an A/B test is designed to support?
In product experimentation, a simple before-after comparison compares metrics across different time periods, which confounds the effect of a feature change with external temporal factors such as seasonality, day-of-week patterns, concurrent marketing campaigns, macro trends, and natural user maturation. Randomization assigns eligible units simultaneously to treatment and control groups, balancing both observed and unobserved confounding variables across groups in expectation. This establishes internal validity. The core causal claim supported by an A/B test relies on counterfactual reasoning: because the control group is subjected to the exact same external conditions over the exact same time window, it serves as an empirical estimate of the counterfactual—what would have happened to the treatment group had they not received the feature. Therefore, any statistically significant difference in outcomes can be causally attributed to the treatment intervention.
# Naive Before-After Comparison:
# Effect_estimate = Metric_t1 (Holiday Launch) - Metric_t0 (Pre-Holiday Baseline)
# Problem: Lift is confounded by holiday shopping surge and marketing spend.
# Randomized A/B Test:
# Effect_estimate = E[Metric_Holiday | Treatment] - E[Metric_Holiday | Control]
# Solution: Both arms experience the exact same external shocks simultaneously.
4¿Qué busca lograr habitualmente el análisis exploratorio de datos antes del modelado formal o la experimentación, y cómo se distingue el EDA (Exploratory Data Analysis) del análisis confirmatorio?
El EDA (Exploratory Data Analysis) es un proceso abierto cuyo objetivo es comprender la estructura subyacente de un conjunto de datos, descubrir patrones, identificar anomalías o problemas de calidad en los datos, evaluar supuestos de distribución y generar hipótesis antes de construir modelos estadísticos formales o realizar experimentos. La diferencia fundamental entre el EDA y el análisis confirmatorio radica en su propósito y metodología: el EDA está orientado a generar hipótesis, es flexible y exploratorio, empleando resúmenes descriptivos, correlaciones y visualizaciones para explorar lo que sugieren los datos sin compromisos previos estrictos. Por el contrario, el análisis confirmatorio (como las pruebas de hipótesis o la evaluación de pruebas A/B) está orientado a contrastar hipótesis, es estructurado e inferencial, diseñado para evaluar rigurosamente hipótesis falsables predefinidas mientras se controlan las tasas de error estadístico (por ejemplo, el error de Tipo I). Tratar los hallazgos descubiertos durante el EDA como conclusiones confirmadas sobre el mismo conjunto de datos puede provocar dragado de datos (p-hacking) y sobreajuste.
import numpy as np
import pandas as pd
# 1. EDA Phase: Open-ended discovery and hypothesis generation
df = pd.DataFrame({'engagement_score': np.random.normal(50, 10, 1000)})
summary = df['engagement_score'].describe()
# 2. Confirmatory Phase: Testing pre-registered hypothesis on fresh test/experiment data
# (e.g., two-sample t-test with fixed significance level alpha = 0.05)
5¿Qué es el target leakage en un entorno de aprendizaje supervisado y en qué se diferencia de una correlación fuerte legítima entre una característica y la etiqueta?
El target leakage ocurre cuando una característica incluida en el entrenamiento del modelo contiene información sobre la etiqueta objetivo que no estaría legítimamente disponible en el momento de la inferencia cuando el modelo realiza predicciones en el mundo real. Esto ocurre con frecuencia cuando una característica se recopila cronológicamente después del evento de interés o es una consecuencia directa o posterior del resultado objetivo (como usar una marca de tiempo de cancelación de cuenta o un identificador de reembolso para predecir la pérdida de clientes). Por el contrario, una correlación fuerte legítima refleja una relación predictiva o causal genuina y preexistente que se conoce completamente y está disponible antes del momento de la predicción (como la frecuencia de inicio de sesión de un cliente durante los últimos 30 días). Aunque ambos mostrarán una alta importancia de las características o métricas de evaluación sólidas, un modelo con target leakage obtendrá puntuaciones de validación offline irrealmente altas, pero fallará en producción porque la característica con fuga no se puede conocer en el momento de la inferencia.
# Scenario: Predicting whether a user will cancel their subscription (is_churned)
# LEAKY FEATURE:
# 'cancellation_survey_submitted' -> Occurs after the decision to churn has executed.
# LEGITIMATE FEATURE:
# 'login_count_last_30_days' -> Observed strictly before the prediction cut-off date.
6¿Cuál es el propósito de particionar los datos en conjuntos de entrenamiento, validación y prueba, y cómo debe guiar cada partición el desarrollo iterativo del modelo?
Particionar los datos en conjuntos de entrenamiento, validación y prueba aísla el ajuste del modelo, la optimización de hiperparámetros y la evaluación final para garantizar la generalización a datos no vistos.
- Conjunto de entrenamiento: se utiliza para ajustar los parámetros internos del modelo (por ejemplo, pesos y sesgos en redes neuronales o umbrales de división en árboles).
- Conjunto de validación: se utiliza durante el desarrollo iterativo para la selección de modelos, el ajuste de hiperparámetros, la selección de características y la detección de sobreajuste. Guía las decisiones sobre qué arquitectura o configuración de modelo funciona mejor sin tocar los datos de evaluación final.
- Conjunto de prueba: sirve como una muestra estrictamente reservada para representar datos de producción no vistos. Se evalúa solo una vez al final del proyecto para proporcionar una estimación imparcial del error de generalización. Reajustar modelos basándose en los resultados del conjunto de prueba invalida su objetividad e introduce un sesgo optimista.
from sklearn.model_selection import train_test_split
from sklearn.datasets import make_classification
X, y = make_classification(n_samples=1000, n_features=10, random_state=42)
# Step 1: Split off final test set (20%)
X_dev, X_test, y_dev, y_test = train_test_split(
X, y, test_size=0.20, random_state=42, stratify=y
)
# Step 2: Split remaining development data into train (75% of dev = 60% total) and validation (25% of dev = 20% total)
X_train, X_val, y_train, y_val = train_test_split(
X_dev, y_dev, test_size=0.25, random_state=42, stratify=y_dev
)
print(f"Train size: {len(X_train)}, Val size: {len(X_val)}, Test size: {len(X_test)}")
7¿Cuál es la diferencia entre el aprendizaje supervisado y el no supervisado, y cómo determinan la disponibilidad de etiquetas y los objetivos de negocio qué paradigma elegir?
Los algoritmos de aprendizaje supervisado aprenden un mapeo matemático desde las características de entrada (X) hacia etiquetas objetivo conocidas (y) utilizando datos históricos etiquetados para predecir resultados en observaciones no vistas. El aprendizaje no supervisado analiza conjuntos de datos que solo contienen características (X) para descubrir estructuras intrínsecas, agrupaciones naturales (clustering) o representaciones reducidas sin etiquetas objetivo predefinidas. La elección entre ambos paradigmas está determinada por la disponibilidad de etiquetas y los objetivos del negocio: si existen etiquetas de verdad fundamental (ground truth) o es viable recopilarlas, y el objetivo de negocio es la predicción dirigida (por ejemplo, detección de fraude, predicción de abandono de clientes o pronóstico de precios), el aprendizaje supervisado es el adecuado. Si no existen etiquetas de referencia, su obtención es excesivamente costosa o el objetivo es la exploración abierta (por ejemplo, segmentación de clientes o detección de anomalías sin etiquetas conocidas), se elige el aprendizaje no supervisado.
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.cluster import KMeans
X = np.array([[10, 2], [12, 3], [1, 8], [2, 9]])
y = np.array([0, 0, 1, 1])
# Supervised: Learns mapping X -> y
clf = LogisticRegression().fit(X, y)
# Unsupervised: Discovers clusters directly from X
kmeans = KMeans(n_clusters=2, random_state=42, n_init=10).fit(X)
8¿Qué es una North Star Metric y cómo se distingue una North Star efectiva de una métrica de vanidad al evaluar la salud de un producto?
Una North Star Metric (NSM) es la métrica principal que mejor captura el valor esencial que un producto ofrece a sus clientes, impulsando al mismo tiempo resultados de negocio sostenibles (por ejemplo, 'Noches reservadas' para Airbnb o 'Horas semanales activas de streaming' para una plataforma de música). Alinea a los equipos de producto en torno al valor para el cliente a largo plazo en lugar del crecimiento superficial.
Para distinguir una North Star efectiva de una métrica de vanidad:
1. **Alineación con el valor:** Una North Star efectiva refleja la utilidad real para el usuario y su interacción activa, mientras que una métrica de vanidad mide un volumen superficial (como el total de usuarios registrados, descargas acumuladas de la aplicación o páginas vistas en bruto) que puede crecer incluso cuando los usuarios abandonan el producto de inmediato.
2. **Capacidad de acción y correlación:** Una North Star efectiva se correlaciona con la retención de usuarios, la salud del producto y la monetización, y responde directamente a las mejoras en la calidad del producto. Las métricas de vanidad a menudo no se pueden vincular a una retención genuina ni a la salud del negocio, y son propensas a la inflación superficial.
Platform: Vacation Rental App
Vanity Metric: Cumulative app downloads (increases continuously even if 95% of users uninstall immediately).
North Star Metric: Nights booked per active user (reflects actual value exchange between guests and hosts).
9¿Cuál es la distinción práctica entre data drift y concept drift, y por qué clasificarlos correctamente es esencial para el mantenimiento de un modelo tras su despliegue?
El data drift (a menudo denominado covariate shift) ocurre cuando la distribución estadística de las características de entrada P(X) cambia con el tiempo, mientras que la relación condicional entre las entradas y el objetivo P(Y|X) permanece inalterada. En contraste, el concept drift ocurre cuando la relación subyacente entre las entradas y el objetivo P(Y|X) cambia, lo que significa que valores idénticos de características ahora corresponden a comportamientos o resultados objetivo diferentes. Clasificarlos correctamente es vital para el mantenimiento posterior al despliegue porque sus estrategias de remediación difieren sustancialmente. Con el data drift, los patrones históricos siguen siendo válidos; el mantenimiento se enfoca en expandir la cobertura de entrenamiento hacia nuevas regiones de características, actualizar el preprocesamiento o aplicar reponderación de muestras. Con el concept drift, las etiquetas históricas dejan de reflejar la realidad actual; el mantenimiento requiere recopilar nuevos datos etiquetados, descartar ejemplos históricos obsoletos y reentrenar o rediseñar el modelo.
# Data Drift (Covariate Shift):
# User demographics or devices change (P(X) shifts),
# but genuine vs fraudulent transaction patterns remain identical (P(Y|X) unchanged).
# Concept Drift:
# Fraudsters adapt tactics to mimic normal shopping patterns;
# identical feature inputs now have a higher probability of fraud (P(Y|X) shifts).
10¿Cuál es la diferencia entre un parámetro poblacional y un estadístico muestral, y cómo influye la variabilidad muestral en la interpretación de métricas?
Un parámetro poblacional es una característica numérica fija y normalmente desconocida de una población completa (como la verdadera media poblacional μ o la proporción p). Un estadístico muestral es un resumen numérico calculado a partir de datos muestrales observados (como la media muestral x̄ o la proporción muestral p̂), que se utiliza para estimar el parámetro desconocido. La variabilidad muestral se refiere a la variación natural de los estadísticos muestrales entre diferentes muestras aleatorias extraídas de la misma población. Debido a la variabilidad muestral, cualquier métrica muestral individual está sujeta a error aleatorio y rara vez coincide con exactitud con el verdadero parámetro poblacional. Al interpretar métricas, no tener en cuenta esta variabilidad lleva a confundir el ruido con cambios reales. Los analistas deben cuantificar la incertidumbre de la estimación utilizando errores estándar, intervalos de confianza o pruebas de hipótesis antes de concluir que una diferencia observada es genuina.
import numpy as np
# True population parameter (mean = 50, standard deviation = 10)
pop_mean = 50.0
pop_std = 10.0
# Draw multiple independent samples of size n=30
np.random.seed(42)
sample_means = [np.mean(np.random.normal(pop_mean, pop_std, size=30)) for _ in range(5)]
for i, sm in enumerate(sample_means, 1):
print(f"Sample {i} Mean (Statistic): {sm:.2f} | Error: {sm - pop_mean:+.2f}")
11Un interesado (stakeholder) hace una pregunta ambigua como «¿Está funcionando la funcionalidad Y?». ¿Cómo reformulas esa solicitud en un marco de análisis medible y orientado a la toma de decisiones?
Cuando un stakeholder pregunta «¿Está funcionando la funcionalidad Y?», comienzo descomponiendo la pregunta en su intención subyacente: ¿qué problema se diseñó para resolver la funcionalidad Y, a quién está dirigida y qué decisión se tomará en función de la respuesta (por ejemplo, iterar, escalar o dar de baja)? A continuación, establezco un marco de medición multinivel compuesto por: 1. Adopción e interacción: ¿los usuarios objetivo están descubriendo y usando la funcionalidad como se esperaba? 2. Valor directo / éxito de la tarea: ¿los usuarios completan con éxito el flujo de trabajo principal habilitado por la funcionalidad? 3. Impacto de negocio derivado: ¿la adopción de la funcionalidad se correlaciona con métricas clave de alto nivel o las impulsa (por ejemplo, retención, conversión, ingresos)? 4. Métricas de control (guardrails): ¿ha generado la funcionalidad efectos secundarios negativos no deseados (por ejemplo, aumento de latencia, tickets de soporte, canibalización)? Por último, predefino los umbrales de decisión y los criterios de evaluación con el stakeholder antes de ejecutar el análisis, asegurando la alineación sobre qué constituye el éxito y evitando cambios retrospectivos en las metas.
Feature: Quick Checkout Button
1. Primary Decision: Keep & expand vs. Redesign vs. Deprecate
2. Evaluation Metrics:
- Adoption: % of checkout sessions clicking the quick button (Target: >= 15%)
- Funnel Completion: Checkout completion rate given button click (Target: >= 75%)
- Business Metric: Overall cart conversion lift (Target: +1.5% in A/B test)
- Guardrail: Support tickets for accidental purchases (Threshold: < 0.2% increase)
3. Pre-agreed Action Plan:
- If Target Met: Roll out to 100% and promote to mobile app.
- If Adoption Low but Completion High: Retain, optimize UI discovery.
- If Guardrail Exceeded: Halt rollout, add confirmation step.
12Al limpiar y preparar un conjunto de datos con una cantidad sustancial de valores faltantes, ¿cómo decides entre el análisis de casos completos, la imputación simple, los indicadores de ausencia y la imputación basada en modelos?
Elegir una estrategia para datos faltantes depende principalmente del mecanismo de ausencia (MCAR, MAR, MNAR), la proporción de datos faltantes, el caso de uso final (inferencia estadística frente a modelado predictivo) y el riesgo de sesgo:
1. **Análisis de casos completos (eliminación de filas):** Apropiado únicamente cuando los datos son completamente aleatorios (MCAR, Missing Completely at Random) y la fracción faltante es pequeña (por ejemplo, <5%). Si los datos son faltantes al azar (MAR, Missing at Random) o no aleatorios (MNAR, Missing Not at Random), eliminar filas introduce un sesgo de selección severo y descarta potencia muestral valiosa.
2. **Imputación simple (media/mediana/moda):** Rápida y práctica para modelos predictivos base, pero peligrosa para el análisis estadístico porque reduce artificialmente la varianza de las variables, infla los estadísticos de prueba y distorsiona las estructuras de covarianza.
3. **Indicadores de ausencia (imputación + flag binario):** Ideal para modelado predictivo (especialmente algoritmos basados en árboles) y casos donde la ausencia aporta información (MNAR, como campos opcionales omitidos). Conserva la señal de ausencia sin corromper las distribuciones numéricas válidas.
4. **Imputación basada en modelos (KNN, MICE, IterativeImputer):** Preferible cuando los datos son MAR, las correlaciones entre variables son fuertes y es crítico preservar las relaciones multivariadas o los errores estándar de los parámetros (por ejemplo, en inferencia de regresión). Sus desventajas son la complejidad computacional, la sobrecarga de implementación en los pipelines de producción y el riesgo de fuga de datos (data leakage) si no se ajusta estrictamente sobre los folds de entrenamiento.
from sklearn.impute import SimpleImputer
import pandas as pd
df = pd.DataFrame({'income': [50000, None, 75000, None, 120000]})
# Impute median while tracking missingness pattern
imputer = SimpleImputer(strategy='median', add_indicator=True)
imputed_data = imputer.fit_transform(df)
# Returns: [income_imputed, income_is_missing]
13Un equipo de producto compara a los usuarios que decidieron activar voluntariamente una nueva funcionalidad frente a los que no lo hicieron, observando una tasa de retención un 20 % mayor. ¿Cómo diagnosticarías el sesgo de selección y la confusión (confounding), y cómo rediseñarías la evaluación?
Comparar a los usuarios que eligen activar voluntariamente una funcionalidad frente a los que no lo hacen sufre de sesgo de autoselección y variables de confusión (confounding). Los usuarios que deciden activamente adoptar una nueva funcionalidad suelen tener una mayor intención de uso, engagement o destreza técnica de base. Como resultado, la diferencia de retención observada del 20 % combina el verdadero efecto causal de la funcionalidad con la motivación previa del usuario.
Diagnóstico del sesgo:
1. **Comparación de covariables previas al tratamiento:** Compara los atributos base entre la cohorte que activó la funcionalidad y la que no antes del lanzamiento (por ejemplo, actividad histórica, retención previa, antigüedad, frecuencia de transacciones o distribución de dispositivos). Diferencias significativas confirman la presencia de confusión.
2. **Comprobaciones de tendencias previas / placebos:** Evalúa si los usuarios que la activaron ya mostraban mayor retención o engagement en periodos previos al lanzamiento de la funcionalidad.
Rediseño de la evaluación:
- **Experimento aleatorizado (estándar de referencia):** Implementa un Randomized Encouragement Design (o un despliegue aleatorizado de la funcionalidad). Todos los usuarios elegibles se asignan aleatoriamente al grupo de Tratamiento (se les ofrece/muestra la funcionalidad) y al grupo de Control (no se les ofrece). Analiza usando ITT (Intention-to-Treat) para el efecto general de la oferta, y Variables Instrumentales / Mínimos Cuadrados en Dos Etapas (2SLS, Two-Stage Least Squares) utilizando la asignación como instrumento para estimar el LATE (Local Average Treatment Effect) sobre los adoptantes activos.
- **Enfoques cuasiexperimentales (si la aleatorización no es viable):** Utiliza Propensity Score Matching (PSM), Diferencias en Diferencias (DiD, Difference-in-Differences) o Control Sintético para ajustar por factores de confusión observables en la línea base y tendencias paralelas preexistentes.
import statsmodels.formula.api as smf
import pandas as pd
# df columns: ['user_id', 'post_period', 'opted_in', 'retained']
# Interaction term captures causal lift above baseline group differences
model = smf.ols('retained ~ opted_in + post_period + opted_in:post_period', data=df).fit()
print(model.summary().tables[1])
14¿Cómo diseñaría los cortes de cohortes para una investigación de activación o retención con el fin de garantizar que las comparaciones no se vean distorsionadas por cambios en la composición de la muestra o por el truncamiento por madurez?
Para diseñar cortes de cohortes que eviten distorsiones por cambios en la composición de la muestra y por truncamiento por madurez: 1. **Estandarizar las ventanas de antigüedad (tenure)**: Alinear las cohortes por antigüedad relativa (por ejemplo, Día 0, Día 7, Día 30 tras el registro o activación) en lugar de por fechas del calendario, garantizando comparaciones homogéneas a lo largo del ciclo de vida. 2. **Gestionar el truncamiento por madurez (censura por la derecha)**: Evaluar únicamente aquellas cohortes que hayan madurado por completo dentro de la ventana de observación. Excluir o marcar explícitamente las cohortes recientes que no hayan tenido la duración completa para alcanzar el hito. 3. **Mitigar los cambios en la composición (mix shifts)**: Segmentar las cohortes según dimensiones de confusión relevantes (como canal de adquisición, plataforma, país o intención del usuario). Si se presenta una métrica agregada, aplicar ponderaciones por estandarización o postestratificación para que los cambios en la mezcla de fuentes de adquisición no distorsionen la tendencia de retención percibida.
WITH user_cohorts AS (
SELECT
user_id,
DATE_TRUNC('week', signup_time) AS cohort_week,
signup_time,
acquisition_channel
FROM users
-- Exclude cohorts that have not reached 7 full days of maturity
WHERE signup_time <= CURRENT_DATE - INTERVAL '7 days'
),
user_activity AS (
SELECT DISTINCT
c.user_id,
c.cohort_week,
c.acquisition_channel,
1 AS retained_d7
FROM user_cohorts c
JOIN events e ON c.user_id = e.user_id
WHERE e.event_time >= c.signup_time + INTERVAL '7 days'
AND e.event_time < c.signup_time + INTERVAL '8 days'
)
SELECT
c.cohort_week,
c.acquisition_channel,
COUNT(c.user_id) AS cohort_size,
COUNT(a.user_id) AS d7_active_users,
ROUND(100.0 * COUNT(a.user_id) / COUNT(c.user_id), 2) AS d7_retention_pct
FROM user_cohorts c
LEFT JOIN user_activity a ON c.user_id = a.user_id
GROUP BY 1, 2
ORDER BY 1 DESC, 2;
15Durante la evaluación, tu modelo alcanza una métrica inusualmente alta, como un AUC (Area Under the Curve) de 0.99, pero el rendimiento cae drásticamente en shadow testing. ¿Cómo aíslas y verificas de forma sistemática la fuga de la variable objetivo (target leakage)?
Cuando un modelo alcanza una métrica offline poco realista (como un AUC de 0.99) que se desploma en pruebas en la sombra (shadow testing) en producción, la fuga de la variable objetivo (target leakage) es la principal sospechosa. Un flujo de trabajo sistemático de aislamiento y verificación incluye: 1. Importancia y atribución de características: calcular valores SHAP, ganancias de importancia o importancia por permutación para identificar características candidatas con un poder predictivo dominante. 2. Modelos de una sola característica y estudios de ablación: entrenar modelos simples de una sola característica (por ejemplo, árboles de decisión poco profundos o regresión logística) en variables sospechosas individuales. Si una única característica logra una clasificación casi perfecta, es muy probable que esté filtrando la variable objetivo. Eliminar secuencialmente las características sospechosas y medir la caída del rendimiento offline. 3. Auditoría de linaje temporal y marcas de tiempo: verificar las marcas de tiempo exactas de creación y actualización de las características candidatas con respecto a la marca de tiempo de corte de la predicción. Comprobar si el valor de la característica solo se podía conocer después de que ocurriera el evento objetivo (por ejemplo, `cancellation_reason` o `refund_status` completados tras la baja o el contracargo). 4. Verificación del linaje de datos y de ingeniería: revisar el pipeline de datos ascendente y la lógica de mutación de tablas (por ejemplo, tablas mutables actualizadas in situ frente a registros inmutables de solo anexión) para verificar cuándo se pueblan los campos.
from sklearn.metrics import roc_auc_score
from sklearn.tree import DecisionTreeClassifier
leakage_candidates = {}
for col in X_train.columns:
clf = DecisionTreeClassifier(max_depth=2)
clf.fit(X_train[[col]], y_train)
preds = clf.predict_proba(X_test[[col]])[:, 1]
auc = roc_auc_score(y_test, preds)
if auc > 0.85:
leakage_candidates[col] = auc
print("Candidate Leaky Features:", leakage_candidates)
16¿Cómo decides entre la validación cruzada K-Fold estándar, Stratified K-Fold y Group K-Fold al evaluar datos estructurados del mundo real?
La elección entre K-Fold estándar, Stratified K-Fold y Group K-Fold depende de la distribución de la variable objetivo y del grado de independencia entre las filas:
1. **K-Fold estándar**: Divide los datos de forma aleatoria en K subconjuntos (folds) de igual tamaño. Asume que las observaciones son independientes e idénticamente distribuidas (IID) y se utiliza habitualmente para problemas de regresión continua o conjuntos de datos con clases bien equilibradas.
2. **Stratified K-Fold**: Garantiza que cada fold conserve la misma proporción de etiquetas de clase de la variable objetivo que el conjunto de datos original. Resulta fundamental en tareas de clasificación, especialmente cuando existe desbalance de clases, evitando que algunos folds contengan una cantidad insuficiente o nula de muestras de la clase minoritaria.
3. **Group K-Fold**: Asegura que los grupos o entidades individuales (por ejemplo, `user_id`, `patient_id` o `device_id`) no aparezcan simultáneamente en los folds de entrenamiento y de validación. Cuando existen múltiples observaciones de una misma entidad, una partición estándar genera una fuga de datos (data leakage) severa, ya que el modelo memoriza patrones específicos de la entidad en lugar de aprender patrones generalizables. Group K-Fold permite evaluar la capacidad real del modelo para generalizar ante entidades completamente nuevas.
17¿Cómo eliges entre regresión logística, árboles de decisión con potenciación del gradiente (GBDT, Gradient Boosted Decision Trees) y arquitecturas neuronales no lineales para clasificación tabular bajo restricciones de latencia y desvío de datos (drift)?
Elegir entre regresión logística (LR, Logistic Regression), árboles de decisión con potenciación del gradiente (GBDT, Gradient Boosted Decision Trees) y redes neuronales (NN, Neural Networks) para clasificación tabular implica equilibrar la capacidad predictiva, los presupuestos de latencia de inferencia, la explicabilidad y la resiliencia al desvío de datos (data drift).
1. **Regresión logística**: Destaca en entornos de latencia ultrabaja (<1-5 ms en p99) y presupuestos de cómputo muy reducidos. Debido a que su cálculo de puntuación es un producto escalar simple, es extremadamente rápida y robusta. Ante el desvío de covariables (covariate drift) o valores fuera de distribución, los modelos lineales extrapolan de forma monótona, lo cual puede ser predecible o peligroso según las pendientes regularizadas, pero rara vez producen un comportamiento errático en forma de función escalonada. Sin embargo, requiere una ingeniería de características manual exhaustiva (interacciones, discretización no lineal) para igualar a las arquitecturas no lineales.
2. **GBDT** (como XGBoost, LightGBM o CatBoost): Son el referente estándar de la industria para datos tabulares. Capturan interacciones no lineales complejas de forma nativa y gestionan tipos de datos mixtos y valores faltantes sin problemas. En términos de latencia, los GBDT optimizados (o compilados mediante Treelite/ONNX) cumplen fácilmente con acuerdos de nivel de servicio (SLA) inferiores a 10 ms. Ante el drift, los GBDT no pueden extrapolar más allá de los límites observados en el entrenamiento (acotando las predicciones en las hojas extremas), lo que proporciona una barrera de seguridad contra extrapolaciones descontroladas, pero arriesga predicciones escalonadas obsoletas si la distribución de las características cambia significativamente.
3. **Arquitecturas neuronales** (como FT-Transformer, TabNet o MLP): Se prefieren cuando los datos tabulares son multimodales (combinados con texto, embeddings o imágenes) o en escenarios de aprendizaje continuo online. No obstante, las redes neuronales puramente tabulares suelen tener latencias de inferencia más altas (requieren multiplicaciones de matrices a través de capas o aceleración por GPU), son más costosas computacionalmente de entrenar y son muy sensibles a entradas no escaladas y al desvío de covariables.
En la práctica: comienza con GBDT como una línea base de rendimiento sólida; si se exige una latencia estricta en microsegundos o una explicabilidad simple, despliega regresión logística; utiliza redes neuronales principalmente para arquitecturas multimodales o transferencia de embeddings.
decision_matrix = {
"Logistic Regression": {"Latency": "<1ms (Ultra-low)", "Drift Behavior": "Linear extrapolation", "Tabular Baseline": "Moderate (needs feature engineering)"},
"GBDT (XGB/LightGBM)": {"Latency": "1-15ms (Fast)", "Drift Behavior": "Leaf clamping (no extrapolation)", "Tabular Baseline": "State of the Art"},
"Tabular Neural Net": {"Latency": "10-50ms+ (Higher)", "Drift Behavior": "Nonlinear extrapolation", "Tabular Baseline": "Competitive / High tuning cost"}
}
for model, traits in decision_matrix.items():
print(f"{model}: Latency={traits['Latency']}, Tabular Perf={traits['Tabular Baseline']}")
18El equipo directivo debe decidir si ejecutar el lanzamiento a nivel nacional de una funcionalidad importante bajo condiciones ambiguas, incluidos resultados dispares de experimentación regional y ventanas de lanzamiento fijas. ¿Cómo diseñarías el marco de trabajo para la recomendación estratégica?
Para estructurar una recomendación estratégica ante resultados dispares de experimentación regional y ventanas de lanzamiento fijas, es necesario desacoplar la decisión de una simple elección binaria de sí o no (go/no-go).
En primer lugar, descompón los resultados agregados en efectos de tratamiento heterogéneos a través de segmentos de mercado, cohortes de clientes y entornos operativos para aislar en qué escenarios la funcionalidad tiene éxito, se estanca o genera un impacto negativo.
En segundo lugar, diseña una estrategia de despliegue gradual con cobertura de riesgos (como un escalonamiento regional o despliegues canario) que priorice los segmentos de alta confianza mientras aísla el riesgo de cola negativa.
En tercer lugar, establece métricas de control (guardrail metrics) explícitas y preacordadas, junto con disyuntores automáticos y umbrales de reversión (rollback) para limitar el riesgo en el peor de los casos.
Por último, enfoca la comunicación ejecutiva en torno al valor esperado, la asimetría del riesgo a la baja frente al coste comercial de perder la ventana fija de lanzamiento, y manuales operativos (playbooks) para pivotar sobre la marcha.
| Rollout Tier | Target Markets | Launch Exposure | Guardrail Circuit-Breaker | Expected Value / Risk Profile |
|---|---|---|---|---|
| Tier 1: Immediate Launch | Cohorts with stat-sig positive lift (e.g., Regions A, C) | 100% | Rollback if 48h conversion drops > 1.5% | High upside; verified market fit |
| Tier 2: Phased Staging | High-variance / neutral cohorts (e.g., Region B) | 10% -> 25% -> 50% over 14 days | Hold expansion if CSAT drops > 2.0% | Moderate upside; bounded downside |
| Tier 3: Hold & Re-test | Stat-sig negative cohorts (e.g., Region D) | 0% (Holdout / internal testing) | Launch blocked until root-cause resolution | Eliminates primary churn risk |
19¿Cómo diseñaría la arquitectura de una capa semántica centralizada en un almacén de datos empresarial para garantizar definiciones coherentes de métricas de negocio entre distintos equipos de analítica?
Diseñar la arquitectura de una capa semántica centralizada en un almacén de datos empresarial requiere establecer una capa declarativa basada en código para la definición de métricas (como MetricFlow/dbt Semantic Layer, Cube o LookML) que desacople la lógica de negocio del almacenamiento físico y de las herramientas de consumo posteriores (plataformas de BI, cuadernos de Python/R, API). La arquitectura central define entidades, dimensiones, medidas y métricas derivadas en repositorios con control de versiones (Git) para proporcionar una única fuente de verdad y garantizar la coherencia de las métricas entre equipos. Para admitir la multitenencia y la gobernanza entre distintas unidades de negocio, se debe utilizar un modelo de gobernanza federado: los KPI empresariales principales (por ejemplo, ARR, usuarios activos) son propiedad de un equipo central de gobernanza de datos, mientras que las métricas específicas de cada dominio son administradas por equipos de dominio descentralizados mediante modelos semánticos aislados con validación en CI/CD. La capa semántica expone luego interfaces de consulta estandarizadas (SQL, GraphQL, REST) con control de acceso basado en roles unificado y almacenamiento en caché/preagregación para mantener el rendimiento y la coherencia.
semantic_model:
name: orders
node_relation:
alias: fct_orders
dimensions:
- name: order_date
type: time
type_params:
time_granularity: day
- name: country
type: categorical
measures:
- name: total_revenue
expr: revenue_usd
agg: sum
- name: distinct_buyers
expr: user_id
agg: count_distinct
metrics:
- name: average_order_value
description: "Governed metric for AOV across all BI tools"
type: ratio
type_params:
numerator: total_revenue
denominator: distinct_buyers
20En un mercado bilateral (como plataformas de viajes compartidos o comercio electrónico), ¿cómo diseñaría un experimento para evaluar un cambio en el algoritmo de emparejamiento teniendo en cuenta la canibalización entre oferta y demanda y la interferencia espacio-temporal?
En los mercados bilaterales, evaluar algoritmos de emparejamiento mediante pruebas A/B estándar a nivel de usuario infringe el supuesto de valor de tratamiento unitario estable (SUTVA, por sus siglas en inglés: Stable Unit Treatment Value Assumption). Cuando las unidades de tratamiento consumen recursos compartidos escasos (como conductores o inventario), canibalizan a las unidades de control, lo que genera una degradación artificial del grupo de control y magnifica los efectos del tratamiento debido a cambios en el equilibrio del mercado. Para abordar la interferencia espacial y temporal, empleamos dos arquitecturas experimentales principales: aleatorización basada en clústeres y experimentos switchback (por bloques de tiempo). En la aleatorización por clústeres espaciales, los mercados geográficos o las subregiones aisladas (por ejemplo, áreas metropolitanas discretas o celdas espaciales hexagonales particionadas por grafos) se asignan aleatoriamente al grupo de tratamiento o de control. Esto aísla las interacciones directas entre oferta y demanda, aunque requiere métodos como controles sintéticos o diferencias en diferencias para gestionar la heterogeneidad entre mercados. En los experimentos switchback, mercados aislados enteros alternan entre los algoritmos de tratamiento y control a lo largo de ventanas de tiempo discretas (por ejemplo, alternando cada 1 o 2 horas). Los switchbacks mantienen un equilibrio común entre oferta y demanda dentro de cada ventana, pero introducen un sesgo de arrastre temporal (*carryover bias*). Para mitigar este sesgo en los switchbacks, se introducen periodos de amortiguación o lavado (*washout*) entre ventanas (descartando pedidos durante las transiciones de estado) y se seleccionan duraciones de ventana suficientemente largas para absorber el reposicionamiento de la oferta, pero lo bastante cortas para retener potencia estadística. El análisis debe tener en cuenta los errores de series temporales correlacionados serialmente agrupando los errores estándar a nivel de bloque temporal/mercado o utilizando ecuaciones de estimación generalizadas (GEE) / estimadores de varianza de Newey-West.
import pandas as pd
import numpy as np
def generate_switchback_schedule(n_days=14, window_minutes=60, washout_minutes=15):
total_windows = int((n_days * 24 * 60) / window_minutes)
np.random.seed(42)
treatments = np.random.binomial(1, 0.5, size=total_windows)
schedule = []
for i, trt in enumerate(treatments):
start_min = i * window_minutes
eval_start_min = start_min + washout_minutes
end_min = (i + 1) * window_minutes
schedule.append({
'window_id': i,
'treatment': trt,
'start_min': start_min,
'eval_start_min': eval_start_min,
'end_min': end_min
})
return pd.DataFrame(schedule)